heh, so it can be other way - type-of-collection forces order-by...
On Thursday 15 May 2008 21:29:24 Michael Bayer wrote:
> it should be considered that when you use hibernate, the collection
> type is explicit with the collection mapping itself; and when you
> use the type, a is required (which
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
> 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
it should be considered that when you use hibernate, the collection
type is explicit with the collection mapping itself; and when you use
the type, a 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 times have
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
like
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 -- unl
> 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 "list"but then that might be too
> steep a change
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 multi
> 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,
> 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 c
10 matches
Mail list logo
