Re: Default collection class for unordered relations

Nick Murphy wrote:
>> 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: ...'
> 
> I have to disagree: it's hardly nannying as much as it is representing
> the underlying reality with greater fidelity.  Relations in SQL are by
> definition unordered, so there's something of an logical mismatch in
> representing them with a type for which order is defined.

There's no disagreement from me on that.  I just don't see purity 
winning out over practicality here.

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---