[sqlalchemy] Empty inserts and objects with no attributes
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 a common workaround for this? Thanks, Nick --~--~-~--~~~---~--~~ 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 sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Empty inserts and objects with no attributes
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 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 a common workaround for this? empty inserts are supported at least by mysql, pg, oracle, and newer versions of SQLite (via INSERT...DEFAULT VALUES which SQLA invokes automatically). Its a database dependent issue so let us know what DB you're using. Thanks, Nick --~--~-~--~~~---~--~~ 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 sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] 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@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 -~--~~~~--~~--~--~---
[sqlalchemy] 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@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 -~--~~~~--~~--~--~---
[sqlalchemy] 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 listbut 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@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 -~--~~~~--~~--~--~---
[sqlalchemy] 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@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 -~--~~~~--~~--~--~---
