> judging by the slapdown in this ticket, and it looks safe to say that > this behavior in SQLite will never change: > > http://www.sqlite.org/cvstrac/tktview?tn=2553 backend of
Yow - that is a pretty terse slapdown! It doesn't seem like sqlite will ever support it. I keep hoping that sqlalchemy can be abstract enough that it will enable the use of any database backend. Stuff like this sqlite composite PK hiccup is discouraging, but I'm convinced there is a workaround to make this work! I don't care if it is the fastest way, it just has to work. I'm trying to get this to work with logic along these lines: 1. Identify in SQLiteCompiler.visit_insert when a primary key is missing from the insert (insert_stmt) 2. If the missing key is tagged as autoincrement, auto-add it to the insert object with a bogus value before the insert is processed (and flag it for use later when working with the execution context) 3. When subbing the variables into the INSERT statement later, replace the bogus value with something like: "(SELECT max(id) FROM user)+1" It seems somewhat reasonable in principle to me, but the problems I'm having in reality are: 1. How do I override SQLiteCompiler.visit_insert without modifying SQLA's sqlite.py? I of course want to avoid trashing the base SQLA install, but can't find an override location in the object tree from my session or engine or anything. 2. Even if I could find a way to override visit_insert, I'm having trouble locating a location to stuff the "select max" code in place. Tweaking the statement by creating an SQLiteDialect.do_execute implementation seems like it might work, but it also doesn't seem lke the cleanest way. 3. What internal SQLA structures can I count on staying fixed through revisions? eg: in visit_insert I can use self._get_colparams to figure out what columns have been requested, and I can use insert_stmt.table._columns to figure out what primary key is missing (and if it is supposed to be autoincrement). But I don't know which of those I can actually count on being there in the future! Plus, crawling around internal objects like this just seems like a bad idea. 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? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
