Yeah, when I said 'id', I guess I really meant the primary key. All of your arguments make perfect sense. Consider my mind change, it's better how it is now!
In that case, can I suggest adding a very short explanation of the order_by parameter here: http://www.sqlalchemy.org/docs/orm/tutorial.html#building-a-relationship ? It's already being used in the examples, but it isn't mentioned in the text surrounding them. Although I suppose you have to try to keep things as succinct as possible in the ORM tutorial, or you'd end up with the entire documentation dumped on one page, and no one would ever get through it :) Cameron Jackson Engineering Intern Air Operations Thales Australia Thales Australia Centre, WTC Northbank Wharf, Concourse Level, Siddeley Street, Melbourne, VIC 3005, Australia Tel: +61 3 8630 4591 cameron.jack...@thalesgroup.com.au<mailto:cameron.jack...@thalesgroup.com.au> | www.thalesgroup.com.au<http://www.thalesgroup.com.au> From: sqlalchemy@googlegroups.com [mailto:sqlalchemy@googlegroups.com] On Behalf Of Michael Bayer Sent: Friday, 16 December 2011 3:01 PM To: sqlalchemy@googlegroups.com Subject: Re: [sqlalchemy] Suggestion: Should relationship's order_by parameter default to id? On Dec 15, 2011, at 10:15 PM, Jackson, Cameron wrote: I was just having a problem with a one-to-many relationship array coming out in the wrong order. Looking here<http://www.sqlalchemy.org/docs/orm/relationships.html#relationships-api>, It wasn't too hard to figure out that I needed to do: myFoos = relationship(Foo, order_by = Foo.id) I was a little surprised though that this isn't the default behaviour. Going by the results that I was getting before I fixed the problem, it looked like the default was in order from least to most recently modified. So I'd like to suggest that the default beahviour be to order the array by id, when there is one. Do you actually mean the string name "id" ? Or at least the primary key of the related table ? Complicating factors here include if primary key is composite, if the key is against a value with varied collation behaviors like a unicode string, if the association is many-to-many (and thus a PK is present on the association table), or if sets or dicts, which are unordered, are used, not to mention custom collections where SQLA can't make a decision automatically. That said, I'm sure it would be doable. I think it would be a good improvement, although if it's going to be harder than I realise, it might not be worth it, given that it's so easy to just do it yourself manually. It's actually not hard at all but we removed default order_bys in version 0.5 (see implicit order by removed: http://www.sqlalchemy.org/trac/wiki/05Migration#ObjectRelationalMapping) They introduce performance issues, complicate queries, and introduce occasional configurational difficulties, and we'd prefer users to choose that they want a particular collection to be ordered, and to have a more streamlined and simple behavior in the absence of this choice, not to mention it simplifies various components within the internals, which are in a constant battle to remain as simple as possible (which is still not very simple). SQLAlchemy overall tries as hard as possible to not assume anything about the design of a schema or what kinds of queries are most appropriate. The Python philosophy of "explicit is better than implicit" is in full force here ! Note Hibernate also has no order-by on collections either unless specified: http://docs.jboss.org/hibernate/core/3.6/reference/en-US/html/collections.html#d0e11300 -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en. ------------------------------------------------------------------------- DISCLAIMER: This e-mail transmission and any documents, files and previous e-mail messages attached to it are private and confidential. They may contain proprietary or copyright material or information that is subject to legal professional privilege. They are for the use of the intended recipient only. Any unauthorised viewing, use, disclosure, copying, alteration, storage or distribution of, or reliance on, this message is strictly prohibited. No part may be reproduced, adapted or transmitted without the written permission of the owner. If you have received this transmission in error, or are not an authorised recipient, please immediately notify the sender by return email, delete this message and all copies from your e-mail system, and destroy any printed copies. Receipt by anyone other than the intended recipient should not be deemed a waiver of any privilege or protection. Thales Australia does not warrant or represent that this e-mail or any documents, files and previous e-mail messages attached are error or virus free. ------------------------------------------------------------------------- -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
