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