Nick Murphy wrote: >> mmh. between db's - maybe u're right. But the order will also change >> depending on current hash-values between 2 runs on otherwise same >> system... There's plenty of difficulties to get a repeatable flow for >> tests etc already. > > That's exactly my point in fact -- unless order_by is specified, a > collection with a defined order is illogical. Using an unordered > multiset instead would ensure that users don't accidentally rely on > this behavior. Of course, if order_by is given, a list makes perfect > sense.
Logic that depends on any ordering from a non-ORDER BY result is a bug, but I don't know that the impact of presenting all users with a new, non-standard, non-native collection type and injecting some kind of __eq__ into mapped classes to satisfy a multiset contract is worth it for what amounts to nannying. Not to mention that unless the implementation did something really silly like rand() its internal ordering for each __iter__ call, it doesn't offer a huge safety improvement for the common case of 'for x in obj.collection: ...' --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
