Re: Default collection class for unordered relations

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 <at> googlegroups.com
To unsubscribe from this group, send email to sqlalchemy-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---