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 _______________________________________________ List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class Wiki: http://dbix-class.shadowcatsystems.co.uk/ IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/ Searchable Archive: http://www.mail-archive.com/[email protected]/
