Login | Register
My pages Projects Community openCollabNet

propel
Reply to message

* = Required fields
* Subject
* Body
Attachments
Send reply to
Topic
Author (directly in email)
Please type the letters in the image above.

Original message

Author hlellelid
Full name Hans Lellelid
Date 2006-05-30 18:43:06 PDT
Message Hi guys -

Alan Pinstein wrote:
>> That is correct, yes. I didn't put up any examples of the Query yet,
>> although you can see one in the ticket comments.
>
> Yeah, that looks nice.
>
>> Basically Query holds stuff that isn't strictly a "criteria". Of
>> course, the line is a little grey when it comes to things like HAVING
>> clause, which is a criteria ... but in those cases, the logic is that
>> Query holds things that don't make sense nested like Criteria.
>
> I wouldn't really consider HAVING a grey area. I think it's only grey
> b/c you defined criteria as the "where" clause, but if you change the
> definition of Criteria to be "result set selectors" which is
> semantically what criteria are anyway, then HAVING fits in nicely.
> Although maybe that means that paging should be moved to criteria as well?
>
> The other option would be to make Criteria strictly "where" clause
> stuff, and put HAVING (and LIMIT/OFFSET) into Query.

Yeah, I think Criteria makes more sense as a WHERE-clause for the reason
that Criteria can be nested/related logically. For example:

   $c = BookPeer::createCriteria();
   $c->add(new OrExpr(new EqualExpr(....), new GreaterExpr(....)));

   $c2 = AuthorPeer::createCriteria();
   $c2->add(new AndExpr(new EqualExpr(...), new InExpr(...)));


   $c->add($c2);

So, from that example, you could see that if $c2 had
setLimit()/setOffset​()/setHaving() defined, it would be "lost" when it
was combined with the $c Criteria. So that was my original thinking
with moving that to Query -- which is not an object that can be combined
logically / nested. Hope that makes sense. Now, of course, it could
just be a matter of choosing a better name for Criteria :)


> Also, where does group by go? Does it even need to be handled by
> Criteria? Are criteria *solely* for selecting data which will be used in
> Propel-managed objects?

That's also a good question. I don't know, although I think the system
needs to be a little bit flexible. The reason is that we already use
some of that flexibility -- for example, in the doCount() methods we
create a query that doesn't actually hydrate propel result objects.
That said, I'm not sure we need to support things that Propel probably
doesn't need -- like aliasing for columns.

Yeah, I think Propel 2.0 can definitely be PHP 5.1 only. I'm not sure
about 1.3 ... I suppose if we release a 1.3 it can be 5.1 too. I think
Gentoo considers it stable now, which can be a benchmark of sorts. On
the other hand, I saw on some list today that CentOS still isn't
shipping w/ PHP5 :)

I may check in some more code tomorrow. I've completed the
doUpdate/doDelete()/doInsert() BasePeer methods and have been making
template changes to use new Criteria. There are a few rough edges
still, but I think the system holds up fairly well.

... more to come. Appreciate the feedback & discussion.

Hans