Login | Register
My pages Projects Community openCollabNet

Reply to message

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

Original message

Author tamcy <7am.online@gmail.com>
Full name tamcy <7am.online@gmail.com>
Date 2006-05-31 00:02:11 PDT
Message Hi devs,

PDO support and Criteria2 are what I'm looking for, so I am really
happy to see they're coming to Propel :). I have a concern about order
by clauses and I hope this is on the topic. "Order by" clauses are
mostly but not neccearily columns, e.g. "order by case when no='4'
then 1 when no='1' then 2 when no='2' then 3 end, col2" is possible
(and I just encounter real need to this).

It looks like current Criteria2 is still possible to do so by a, say,
CustomOrderByColumn class. But this class will then be a decendant of
QueryColumn, which doesn't "sound right" because a ColumnMap seems
"too much" for my CustomOrderByColumn class. Also there is no way for
me to add my own CustomOrderByColumn object to the Query class.

Just a thought of implementation, how about:
- There is a OrderBy(for instance) interface
- The OrderByColumn now implements OrderBy extends QueryColumn
- I can have my "class CustomOrderByColumn implements OrderBy"
(actually this CustomOrderByColumn is very general that may even make
it into Propel)
- Current addAscOrderBy and addDescOrderBy should be kept since they
are frequently used
- A new addOrderBy() function that can be used like this:
$query->addOrderBy(new CustomOrderByColumn('case when no='4' then 1
when no='1' then 2 when no='2' then 3 end, col2'));


On 5/31/06, Hans Lellelid <hans at velum dot net> wrote:
> Hi guys -
> 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
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org