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