Login | Register
My pages Projects Community openCollabNet

Discussions > dev > proposal: generated Query classes

propel
Discussion topic

Back to topic list

proposal: generated Query classes

Reply

Author hlellelid
Full name Hans Lellelid
Date 2006-07-12 06:10:37 PDT
Message Hi -

So, I've been using the new Criteria2 system for a month or so now,
fixing little bugs as I find them. Overall it's quite nice, but I think
the simplicity of the system starts to break down when it comes to join
queries with criteria for both tables in the join.

Here's an example of how we would do this in Criteria v1:

$c = new Criteria();
$c->add(BookPeer::NAME, "1984");
$c->add(AuthorPeer::NAME, "George Orwell");
BookPeer::doSelectJo​inAuthor($c);

That is fairly straightforward. Here's how that would look in Criteria v2:

$bc = BookPeer::createCriteria();
$ac = AuthorPeer::createCriteria();
$bc->add(new EqualExpr(BookPeer::NAME, "1984"));
$ac->add(new EqualExpr(AuthorPeer::NAME, "George Orwell"));
$bc->add($ac);
BookPeer::doSelectJo​inAuthor(new Query($bc));

It's two more lines of code, and a fair bit of complexity. And it gets
even more complex when you want to start adding order-by columns and
other Query-level features. The main reason for the added complexity in
Criteria2 is that Criteria (and Query) objects must be linked to the
tables for which they are being used. In Criteria1 the table names were
hard-coded into the constant values, which was very limiting (no table
aliasing, etc.) but made simple queries easy to represent.

While some of the new complexity is simply part of a more flexible
system, I do think that a simpler API is needed for end users. Also, I
want to reduce the size of the generated Peer classes (and maybe object
classes) substantially. My UserPeer class has some 13000 lines of code
in it, which is completely insane to be parsing every request, given
that my app will never use but a small percentage of that. Yes, having
a bytecode compiler reduces the effects of huge classes, but I don't
think it should be a requirement that Propel run with a bytecode compiler.

Recently, I've been thinking some more about the idea of generating
specific Query (sub?)classes for each entity. This might be able to
provide a simpler API and also dramatically the number of methods (and
especially lines of code) in the generated classes.

I'm envisioning an API that would look something like this:

$q = new BookQuery();
$q->add(new EqualExpr(BookPeer::NAME, "1984"));
$aq = $q->selectJoinAuthor();
// maybe selectJoinAuthor() means JOIN and also select columns
// and joinAuthor() means just JOIN the table (but don't select
// additional columns)

$aq->add(new EqualExpr(AuthorPeer::NAME, "George Orwell"));

BookPeer::doSelect($q);


An API like that would make things a bit simpler:
  * Individual criteria can be added to Query in addition to Criteria
(this is probably a nice simplification regardless)
  * BookPeer::doSelect() knows to look at the passed-in Query object to
determine joining, so no doSelectJoinAuthor is needed.
  * A generated BookQuery object ensures relationship between the Query
and the correct table and contains some of those additional methods to
facilitate joins / fk relationships.

I'm curious what you guys think of this before I actually start writing
any code for this. I am open to other API suggestions you might have
too. Perhaps some of you have used other ORMs that have an elegant API
for handling inter-related data?

Hans

« Previous message in topic | 1 of 12 | Next message in topic »

Messages

Show all messages in topic

proposal: generated Query classes hlellelid Hans Lellelid 2006-07-12 06:10:37 PDT
     Re: [propel-dev] proposal: generated Query classes Alan Pinstein <apinstein at mac dot com> Alan Pinstein <apinstein at mac dot com> 2006-07-12 08:00:58 PDT
         Re: [propel-dev] proposal: generated Query classes hlellelid Hans Lellelid 2006-07-12 08:08:27 PDT
             Re: [propel-dev] proposal: generated Query classes Alan Pinstein <apinstein at mac dot com> Alan Pinstein <apinstein at mac dot com> 2006-07-12 09:09:01 PDT
                 Re: [propel-dev] proposal: generated Query classes hlellelid Hans Lellelid 2006-07-12 09:24:10 PDT
     Re: [propel-dev] proposal: generated Query classes Ants Aasma <ants dot aasma at mig dot ee> Ants Aasma <ants dot aasma at mig dot ee> 2006-07-12 09:32:28 PDT
         Re: [propel-dev] proposal: generated Query classes hlellelid Hans Lellelid 2006-07-12 09:48:43 PDT
             Re: [propel-dev] proposal: generated Query classes tamcy <7am dot online at gmail dot com> tamcy <7am dot online at gmail dot com> 2006-07-13 07:01:39 PDT
                 Re: [propel-dev] proposal: generated Query classes hlellelid Hans Lellelid 2006-07-13 07:08:52 PDT
             Re: [propel-dev] proposal: generated Query classes Ants Aasma <ants dot aasma at mig dot ee> Ants Aasma <ants dot aasma at mig dot ee> 2006-07-13 08:50:59 PDT
         Re: [propel-dev] proposal: generated Query classes Alan Pinstein <apinstein at mac dot com> Alan Pinstein <apinstein at mac dot com> 2006-07-12 11:45:12 PDT
     A bit offtopic... Eugene Janusov <eugene at annah dot ru> Eugene Janusov <eugene at annah dot ru> 2006-07-12 12:08:45 PDT
Messages per page: