On Wed, Mar 3, 2010 at 5:57 PM, Aristedes Maniatis <ar..aniatis.org> wrote:
> Having a default ordering for ObjEntities defined in the model is what Rails
> does. Any time you fetch that entity, be it directly through a Query or via
> a relation, you get the results back with that ordering.
>
> Personally I don't see the point. Ordering in the database is very useful if
> you are paging the results. Or using a limit. But when following relations,
> neither of those things applies, so you may as well just do it in memory
> once you have the list returned.
I have to disagree. The way Rails does it handles the most common
cases extraordinarily well. Many objects have some sort of natural
creation order, whether that be through monotonically increasing IDs
or timestamps. In any event, it's quite handy to have:
- "Order.all" return all orders in reverse chronological order
- "customer.orders.all" return all orders in reverse chronological order
So forth and so on.
Certainly this could be done in memory. It just means I'm now adding
template code in all my generated class files that basically do the
same thing and that the framework could handle very easily for me.
I'd really rather have that handled in the data map. I'd event settle
for a class-level annotation for specifying a default sort order.
But, the non-deterministic default return order is usually a bad
default unless I'm really just looking for collection behavior.
-- Kevin
This archive was generated by hypermail 2.0.0 : Sat Mar 13 2010 - 13:40:42 EST