the correct patch would be just a slight modification of what's provided on ticket 1016, adding "table.kwargs['sqlite_autoincrement'] == True" to the checks provided. I would also remove all the "len(pk.columns) == 1" and "Integer" checks since if the user is adding this flag they should know what they're doing. the work here is to add that in, make sure all the unit tests still pass, and the new functionality works too. A specific test added to tests/dialect/ sqlite.py would be ideal.
On May 17, 2009, at 9:40 AM, paniq303 wrote: > Hello, > > how is the progress with this feature - how can I use it? My > application strongly depends on AUTOINCREMENT being available. > > To explain: > > Without AUTOINCREMENT, a deleted primary key will be reassigned. > > As an example: three records are created, with ids 1, 2 and 3. Now the > record with id 3 is being deleted. We create a new record, and this > record will get id 3 again, instead of id 4. In this way, there can be > confusion between the old and the new record with id 3. > > If the primary key has been declared as AUTOINCREMENT, new id's will > never correlate with previously deleted ones. This makes tracking an > item much easier, for both relating records in other tables, and > external routines dealing with undo/redo and diff'ing databases. > > Without this feature, I can't use SQLAlchemy. It would cause more > trouble than it solves. > > Leonard > > On Nov 13 2008, 11:51 am, Michael Bayer <mike...@zzzcomputing.com> > wrote: >> As discussed in trac ticket #1016, we would need to add support to >> Column such that **kwargs with dialect names are parsed, such as >> sqlite_autoincrement=True. The ticket has been accepted and just >> needs someone to contribute a patch. We definitely are not going to >> link the existing "autoincrement" flag to SQLite's AUTOINCREMENT >> keyword - its a very rarely used keyword in SQLite and as their >> documentation states that it causes a degrade in performance - SQLite >> primary key columns are "autoincrementing" in the general sense in >> any >> case, at least as far as that they generate primary key values >> automatically. >> >> The purpose of the existing "autoincrement" is documented, and is >> only >> provided to "turn off" automatic-generate-primary-key behavior for >> databases which have an option in this regard, which does not include >> SQLite. >> >> On Nov 13, 2008, at 4:16 AM, Sok Ann Yap wrote: >> >> >> >>> SQLAlchemy doesn't seem to generate "INTEGER PRIMARY KEY >>> AUTOINCREMENT" column in sqlite, even though the Column has >>> autoincrement=True. According to sqlite website[1], if the >>> AUTOINCREMENT keyword is set, it will use an actual sequence, >>> otherwise it will just grab the largest id + 1. The later behavior >>> caused one of our unit test to fail, and due to our unfamiliarity >>> with >>> SA/sqlite, we spent hours to uncover the cause of the problem. It >>> will >>> be great if SA can set the AUTOINCREMENT keyword in sqlite if the >>> autoincrement argument is set to True. >> >>> Regards, >>> Yap >> >>> [1]http://www.sqlite.org/autoinc.html --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
