Peter Rabbitson wrote:
On Sun, Jul 18, 2010 at 03:25:50PM -0500, David Ihnen wrote:
On Sun, Jul 18, 2010 at 2:30 PM, Leandro Hermida <[email protected]
HQL and JPQL which somewhat resemble SQL but work with objects. I would
imagine a Moose-based DBIC would have one as well?
I would most emphatically scream, NO. Just like DBIX::Class, the 'query
language' would be described through perlish data structures - no
independent syntax. We have enough languages already!
If you use HQL I believe you can actually make a query that fetches all
objects who's related object's attribute X is Y, see here
http://docs.jboss.org/hibernate/core/3.3/reference/en/html/queryhql.html.
I believe it translates HQL into SQL before making the query in a
transparent way.
We have enough language syntaxes already. We do not need to invent, YET
ANOTHER language. I have very strong reservations regarding the
appropriateness of this kind of solution to the ORM problem.
I would argue that there is little semantic difference between describing a
query using Perlish data structures and describing it with strings. From Perl's
point of view, both of these are a piece of data whose format might be
arbitrarily complicated, and are both are interpreted generally using the
command design pattern. Therefore, I would argue that Perlish data structures
*are* another language with independent syntax. The distinction is that the
Perl data structures are easier and less error prone for Perl programs to build,
and so are better to use, but they are still a language.
David, you are spot on, except you are not taking your idea far enough. Yes
we can currently specify queries via concise, clear and (most importantly)
modular perl. The goal however is to erase the bondary between perl and the
underlying storage. In other words to have things like:
my $matches = grep $_->name =~ /wohoo/, $rs;
Execute via an actual SQL RLIKE under the hood. Now *that* is what people
should be excited about, not about "I want to store objects".
Now you're talking! *This* is more like how you actually avoid having another
language, at least in the sense that what you're writing is ordinary Perl code
that looks like its invoking ordinary Perl routines on Perl data structures, and
could in fact alternately be implemented that way. Perl data structures doesn't
avoid the other language, but examples like the above do.
See also DBIx::Perlish for what is probably the closest thing to this that
currently exists for Perl that I know about.
What DBIC and its younger brother are about is making random data more
accessible, not provide yet-another-data-warehousing-framework.
How do you define that? What would a "data-warehousing-framework" do that a
future DBIC or its younger brother would not do?
So if you
or anyone feels excited about this - pop into #dbix-class and ask mst or
frew how you can help.
I should also restate that my Muldis::Rosetta toolkit (not yet useable) is
intended to support your stated goal, erasing the boundary between Perl and the
underlying storage. For now I am helping best by working on M::R, which the
functionality you propose or a future DBIC/etc can be more easily built over
than over generic alternatives.
-- Darren Duncan
_______________________________________________
List: http://lists.scsys.co.uk/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]
