On Fri Sep 07, 2007 at 01:23:48AM +0200, Emanuele Zeppieri wrote:
> Mark Lawrence wrote:
> >There is another *implicit* AND between the two conditions. At first
> >(and second glance) this is very different from the actual intended SQL,
> >not to mention the complexity of other artifical constructs like -nest.
> >A much better mapping can be obtained with Perl's built-in logic operators.
>
> What criteria are you using to evaluate which mapping is better?
>
> It seems that you are talking only about readability by humans, which is
> the less important thing, really.
?!? You are saying code readability by humans is less important than how
easy it is for a computer program to interpret a data structure??
As far as I'm concerned, programs are here to make my life easier, not
the other way around :-) Have you considered that maybe you should be
programming in assembly?
This is the basis for my claim that the mapping is better: I'm aware
of the language structure and limits of the SQL backend. These are the
parameters I understand so the less translation / conversion I have to
do the more efficient my work is. That also doesn't mean I want to work
directly with strings, because Perl data manipulation can do the job
better as you mentioned. So yes, there is a mapping involved.
> On the other hand, I may be wrong (I'm just judging by your messages
> here in the list) but it seems that the syntax you are proposing
> requires instead string manipulations to automate the queries
> generation, which is a thing that leads straight to unmaintainable code.
I'm not sure why people keep thinking SQL::DB requires more string
manipulation than SQL::Abstract. Going back to one of the examples
I first posted:
$schema->query(
select => [$track->title, $cd->year],
from => [$track, $cd],
distinct => 1,
where => ($track->length > 248) & ! ($cd->year < 1997),
union => $query2,
);
The arguments to the query() method is a LIST of keyword / value
pairs (also a data structure). The keywords are not used as strings
in the generated SQL, but are commands to SQL::DB about what type
of data structure follows.
my @query = (
construct_a => $data,
construct_b => $data,
construct_c => $data,
);
It is in fact the same principle as SQL::Abstract but with a
different syntax. Nothing more, nothing less.
Cheers,
Mark.
--
Mark Lawrence
_______________________________________________
List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/[EMAIL PROTECTED]
