[sqlalchemy] Empty inserts and objects with no attributes

2009-10-06 Thread Nick Murphy
Hi, A class of mine has no attributes besides its primary key. This key is a surrogate, so I'd like to assign values automatically via autoincrement. Unfortunately, it's not possible to persist objects of this class to the database, as the SQL compiler complains about empty inserts. Is there

[sqlalchemy] Re: Empty inserts and objects with no attributes

2009-10-06 Thread Nick Murphy
Hi Mike, I'm using SQLite, and I'm tracking svn trunk (I'm at revision 6390). Is the newer sqlite backend you mentioned somewhere else? Thanks, Nick On Oct 6, 8:49 am, Michael Bayer mike...@zzzcomputing.com wrote: Nick Murphy wrote: Hi, A class of mine has no attributes besides its

[sqlalchemy] Default collection class for unordered relations

2008-05-15 Thread Nick Murphy
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,

[sqlalchemy] Re: Default collection class for unordered relations

2008-05-15 Thread Nick Murphy
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

[sqlalchemy] Re: Default collection class for unordered relations

2008-05-15 Thread Nick Murphy
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

[sqlalchemy] Re: Default collection class for unordered relations

2008-05-15 Thread Nick Murphy
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