Scott Marlowe wrote:
On Nov 9, 2007 5:17 AM, rihad <rihad@xxxxxxx> wrote:
Em Wednesday 07 November 2007 13:54:32 rihad escreveu:
May I, as an outsider, comment? :) I really think of ASC NULLS FIRST
(and DESC NULLS LAST) as the way to go. Imagine a last_login column that
sorts users that have not logged in as the most recently logged in,
which is not very intuitive. I vote for sort_nulls_first defaulting to
false in order not to break bc.
But then, when ordering by login date, you should use COALESCE and infinity
for them
(http://www.postgresql.org/docs/8.2/interactive/datatype-datetime.html).
It's not an easy thing to do with for example Propel 1.2 ORM (written in
PHP):
$criteria->addDescendingOrderByColumn(myPeer::LAST_LOGIN); // no place
to shove database-specific attributes in.
Why not create an updatable view that orders the way you want it to?
I've already thought about this, but... there aren't yet truly updatable
views in PostgreSQL, but rather query rewriting a.k.a.
text-substitution; 1) it isn't of paramount importance in my current
case. It just wouldn't be bad to set sort_nulls_first=true, if it existed.
If you wan't to know the full story, prepare for some OT :-)
Because of the way Symfony/Propel does its "object hydration" has
already forced me to write views in postgres to minimize the amount of
data fetched: otherwise Propel is happy to fetch full-records from db,
and all its FK-related objects, too (the lazyLoad misfeature is a
two-sided gun: it pretends it fetches only this many columns for each
row, but if you later access further columns each one will cost you a
separate database hit), all of which is unacceptable for e.g. displaying
a HTML table of N items with pagination etc. Symfony/Propel is also
quite happy to hydrate the full object from db just for save()'ing it
back to db right away (on a form POST for a record update, for example),
which makes my brain hurt, so I went to the trouble of avoiding the
pre-hydration, too. This all resulted in much effort not directly
related to the business logic of my app, but rather on overriding
Symfony's way of doing everyday web-programming tasks (like form
validation, results listing, editing). Now I don't really want to work
around further design inefficiencies of Symfony/Propel by trying
updatable views. Really frustrating. Easier to just forgo any
web-framework and write quality code yourself instead, like
phpclasses.org's Manuel Lemos once said in his article... That said,
Symfony 1.1-DEV/Doctrine begin to look promising.
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
