[Dbix-class] Moose

[Darren Duncan]

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 <softdev at leandrohermida.com
>>
>>>  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