[Dbix-class] Explicit ASTs (ping nate)

[David E. Wheeler]

On Sep 4, 2006, at 15:54, Darren Duncan wrote:

> Well, I'm saying the return type here in the sense to what a SELECT
> conceptually returns.  By implementation-specific, I assume you mean
> what Perl data type is returned, since Perl 5 doesn't have a Table or
> Relation type.

Correct.

> My own impression of a best type of response is that an object is
> returned from which you can either get the resultset all at once, eg
> as an array of hashes, or you can enumerate through it one row at a
> time, etc, such as if you have a large result set that uses a cursor
> behind the scenes since it won't fit in RAM.

That's what most ORMs do, yes, though the iterator usually returns  
objects.

> But still, this matter is largely orthogonal to query syntax, unless
> your query can specify what kind of result you want to conceptually
> be given as a result, eg, all-at-once vs cursor handle.

I like cursors. I just wish that DBD::Pg supported them. :-(

> FYI, I'm writing some pseudo-SQL for each to help illustrate them;

<snip />

Nice, thanks.

> Well, I used the word "inspiration" on purpose.  The point is that
> you can use simpler operators that are used together without those
> operators being the same as any of the above (especially if some DBMS
> products don't easily support some of the above in isolation from a
> combination with others).  The important principle is breaking down
> the bigger problem into clearly defined and easier to use smaller
> ones.

Right, agreed.

> I will also take this moment to point out a brand new book by the
> same authors, which is "The Relational Database Dictionary".  This
> book is more of a pocket reference type thing at 122 pages, and is
> inexpensive.
>
> See: http://www.oreilly.com/catalog/relationaldb/index.html
>
> I've already ordered a copy for myself, today.

Ooh, nice.

>> Yes, but the syntax in pure Perl is hard; see my recent post on p5p
>> for details.
>
> That depends on how you do it.  There are various Perl idioms that  
> can be used.

Well, yes, but I want to do it with Perl expressions and operators,  
not with data structures.

> If you want to generate SQL or other non-Perl things from it, then
> you could make the input more AST-like in appearance.

Blech. Not fun for humans to use.

> If you want it to execute in Perl, you could replace some things with
> anonymous subroutines; eg, a WHERE clause is essentially like Perl's
> "grep" in structure, so you could take an anonymous sub ref that is
> invoked for each row, given that row as its argument, and it returns
> true or false based on whether the row matches its criteria.

Yep, that's what I'm doing, only I'm rewriting the code ref to a  
WHERE clause, rather than filtering the results through the code  
reference. It will look largely the same, though, to the user.  
Getting it just right is really hard, though.

> Note that my Set::Relation module will be taking the latter approach,
> while Rosetta will be taking the former approach.

Yes, we're going for a similar dichotomy here.

> If you don't want either of those approaches, then I don't know
> enough about Perl to do what you want, at least not without more
> prompting or help.

I'm looking at possibly introspecting a code ref without executing  
it, but I don't know enough about B or Perl's internals to do much  
with it yet…I'd be intereseted to see what you've come up with, Darren

Best,

David