Russell Warren wrote: > > 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?
autoincrement is very difficult to implement in application code in an atomic and high performing fashion. If we're not using what the DB engine provides natively, then the user has to pick the method he or she wishes to use, since each would have caveats the user needs to be aware of. I'm not opposed to having a catalog of "id generator" tools within the distro but as of yet nobody has offered any. A key philosophy of SQLA is that we don't make choices for the user without explicit statement. > 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. We abstract as much as is reasonably possible. But we also honor and make explicit the differences between those databases so that each backend can be used to its fullest potential. Another big philosophy of ours is to not pretend the database doesn't exist by forcing all the various vendors into the lowest denominator of functionality. Practices like that are what give object relational tools as well as RDBMS overall a bad name. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
