After looking over the 0.5 migration notes and seeing that implicit
ordering is to be removed, it seems to me that it might make sense
to change the default collection class for unordered relations from
a list to a multiset. This would reinforce that unless order_by is
specified, one
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
On May 15, 2008, at 12:51 PM, Nick Murphy wrote:
Hello Group,
After looking over the 0.5 migration notes and seeing that implicit
ordering is to be removed, it seems to me that it might make sense to
change the default collection class for unordered relations from a
list to a multiset.
if we had a totally explicit collection class is required approach,
that would be something different (like, cant use list as a
collection unless order_by is present). We might just say in any case
that order_by is required with listbut then that might be too
steep a change for 0.4 to
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
I think Jason hits the nail on the head with his response - my first
reaction on the initial post was that was splitting hairs to enforce the
difference between an ordered list and an (allegedly) unordered list, but I
thought it was going to be a non-starter until I read Mike's reply. It seems
it should be considered that when you use hibernate, the collection
type is explicit with the collection mapping itself; and when you use
the list type, a list-index is required (which is also a much
better name here than order_by). So there is the notion that using
a list should at all
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
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
