in reply to Re: Rebuttle to chromatics
in thread Rebuttle to chromatics

SQL is not perl code. Therefore, it should not be in your perl programs. I generally have an 'SQL' directory that I keep one query per .sql file.

Amen.

Now, all my html is loaded via HTML::Template and all my SQL is in external files. I only look at perl when I edit a perl file.

Now here we have some asymmetry. HTML is not Perl code either. Nor is it necessarily non-complex. However, your means of abstracting the two differ. Could you provide us with some input as to why your approaches differ? I think such a post would be one of the first posts to explore and expound some basic means of Perl Software Engineering.

Functions to generate html is very ugly and a nightmare to maintain. So is SQL. Queries are complex business and should probably be written by hand; how many abstractions layers have gotten joins right?

Have you read the docs for DBIx::Recordset. It handles all sorts of joins. Further, what do you plan to do when you want to write those same applications in a database independent form? This is an important question and I want to hear your answer to it. I do have an alternative to Recordset. It is Class::Phrasebook::SQL

Replies are listed 'Best First'.
Re: Re: Re: Rebuttle to chromatics
by DrZaius (Monk) on May 08, 2001 at 22:26 UTC
    Actually, HTML::Template loads the html off the file system. You do something like: 
    my $t = HTML::Template->new(filename => $file);

    [download]
    And pass any dynamic elements in.

    We have an inhouse module called SQL::Serialized which is basically an autoload method that takes the method name, attaches .sql to the file and tries to load the query out of a file with that name.

    We have been toying with releasing it vs rewriting it to use Inline (Inline::SQL). Then, we could also do something like Inline::HTML::Template.

    This probably sounds goofy, but there is one situation in which SQL::Serialized is a massive bitch: utility scrips; the support files (.sql's) either have to be in a hardcoded location or the current directory.

    My idea was to take advantage of using __DATA__ blocks for storing queries so that we don't have to deal with sql files for that. Inline has support for this sort of thing.

    But, as it stands, currently, queries look like this 

    my $dbh = DBI->connect;
my $sql = SQL::Serialized->new(directory => './sql');

my $sth = $dbh->prepare_cached($sql->big_query);
$sth->execute(@place_held);

    [download]
    My views come from the fact that if you change database, you are going to have to change your SQL anyway. Although, one person I know says that if you write all your sql against dbase or some silly, lowest common denominator, databse that isn't the case.
[reply]
[d/l]
[select]

In Section Meditations