On Jun 13, 2008, at 1:00 AM, Russell Warren wrote:
> > Any help is appreciated. I expect I'm in over my head trying to mess > with a dialect implementation. I'm also worried that this will just > be the first of many things like this I'll be trying to overcome to > get SQLA to truly abstract the database implementations away... > > And a related question: What is the general feeling on how well SQLA > abtstracts the underlying database away? Am I expecting too much to > be able to write my application using SQLA-only from the beginning and > have it work on any of the popular databases without much tweaking? > if you'd like to specify a value generator for the columns, just use a ColumnDefault. Whatever function or SQL you like will be called if no value is present - its just in this case we can't rely upon SQLite's OID generation. I wouldn't favor a built in system of "guessing" within the sqlite dialect how to autoincrement a composite PK field without explicit user intervention. The dialects don't intend to build a completely uniform layer over all database backends (for example, when using Oracle, you are required to set up a default generator, usually a Sequence, in all cases) - the idea of a dialect's default behavior is that it uses what the database backend provides by default and that's it. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
