> 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.
Thanks - I'll look into that. I just have to figure out how to make ColumnDefault dialect dependent. > 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. Why not? Is it really guessing when the table has been defined precisely within SQLA? If you have a Column that has been defined to be an Integer primary key that is supposed to autoincrement, and you are using sqlite... how could you be wrong? The worst case I can think of is if sqlite changes in the future to actually support it, in which case you'd either change the dialect or get an error. No? > 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. But at the same time the dialect is also abstracting out many of the annoying backend type differences. I thought that a big part of SQLA was going to be allowing the use of any back end. Maybe I'll have to re-evaluate my approach... more likely I'll just keep plugging away and see what obstacles I hit! --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
