gmane.comp.python.sqlalchemy.user

Nick Murphy | 15 May 18:51

Default collection class for unordered relations


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.  This would reinforce that unless order_by is
specified, one cannot rely on a collection having a particular order.
I could see this as helpful in preventing bugs when switching between
databases (e.g. from MySQL to PostgreSQL) with different default
ordering behaviors.

Regards,
Nick
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

headers

az | 15 May 22:03

Re: Default collection class for unordered relations


> 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 cannot rely on a collection having a particular
> order. I could see this as helpful in preventing bugs when
> switching between databases (e.g. from MySQL to PostgreSQL) with
> different default ordering behaviors.
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.

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

headers

Nick Murphy | 15 May 19:18

Re: Default collection class for unordered relations


> 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
collection with a defined order is illogical.  Using an unordered
multiset instead would ensure that users don't accidentally rely on
this behavior.  Of course, if order_by is given, a list makes perfect
sense.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

headers

jason kirtland | 15 May 19:47

Re: Default collection class for unordered relations

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 order_by is specified, a
> collection with a defined order is illogical.  Using an unordered
> multiset instead would ensure that users don't accidentally rely on
> this behavior.  Of course, if order_by is given, a list makes perfect
> sense.

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: ...'

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

(Continue reading)

headers

Rick Morrison | 15 May 20:06

Re: Default collection class for unordered relations

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 overhead and unneeded complexity for what is really just a reminder. And as his iterative example points out, not a very effective reminder at that.

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

headers

Michael Bayer | 15 May 20:29

Re: Default collection class for unordered relations

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 times have a "list-index", and it is more  
"correct" for sure.  And this does bug me.  I just am not sure if  
we're there yet as far as this kind of setting, if we want to force  
that level of explicitness in a Python lib, etc.  Its something of a  
cultural decision.

On May 15, 2008, at 2:06 PM, Rick Morrison wrote:

> 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 overhead and unneeded complexity for  
> what is really just a reminder. And as his iterative example points  
> out, not a very effective reminder at that.
>
>
> >

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

headers

az | 16 May 00:54

Re: Default collection class for unordered relations


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 <list> type, a <list-index> is required (which is also a
> much better name here than "order_by").   

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

headers

Nick Murphy | 15 May 20:49

Re: Default collection class for unordered relations


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

headers

jason kirtland | 15 May 20:52

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

headers

Michael Bayer | 15 May 19:22

Re: Default collection class for unordered relations

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.  This would reinforce that unless order_by is
> specified, one cannot rely on a collection having a particular order.
> I could see this as helpful in preventing bugs when switching between
> databases (e.g. from MySQL to PostgreSQL) with different default
> ordering behaviors.
>

it is worth considering.   though im not sure if i like the implicit  
"order by changes the default collection class", only because it might  
get kind of confusing.

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 for 0.4 to 0.5, and also it gets a little weird in that  
we dont necessarily know how well the collection is list-like/set-like.

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

headers

Nick Murphy | 15 May 19:39

Re: Default collection class for unordered relations


> 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 for 0.4 to 0.5, and also it gets a little weird in that
> we dont necessarily know how well the collection is list-like/set-like.

Yeah, it's definitely tricky, and I could certainly see the behavior
as confusing to new users.  The pedant in me tends to think that lists
are appropriate only when there is an explicit ordering for a
collection -- as with orderinglist -- and that sets/multisets should
be used in most other circumstances; if an arbitrary order is needed,
the collection can be sorted in Python.  That said, it's really
convenient to not have to worry about that, even if it's not 100%
"correct."
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---