This relates to primary key constraint in SQLAlchemy & sqlautocode. I have SA 0.5.1 & sqlautocode 0.6b1 I have a MySQL table without primary key. sqlautocode spits traceback that "could not assemble any primary key columns".
Can I rectify this with a patch sothat it will reflect tables w/o primary key?
Thanks, Vineet Deodhar
I don't think so. How an ORM is suposed to persist an object to the database without any way to uniquely identify records?
However, most ORMs accept a primary_key argument so you can indicate the key if it is not explicitly defined in the database.
We've succeeded in faking sqa if the there's combination of columns on the underlying table that uniquely identify it.
If this is your own table and you're not live, add a primary key integer column or something.
We've even been able to map an existing legacy table in a database with a) no pk and b) no proxy for a primary key in the other columns. It was Oracle not MySQL but we were able to hack sqa to see Oracle's rowid as a pk, though this is only safe for insert and query...update is not possible since it can't uniquely identify which row it should be updating. But these are ugly hacks so if you can help it, don't go down that road.
If the problem is that sqlautocode will not generate your class code because it cannot determine the PKs of the table, then you would probably be able to change that code to fit your needs (even if it means generating SQLA code that doesn't have PKs). Eventually, if you're using the ORM side of SQLA, you're going to need fields defined as PKs, even if the database doesn't explicitly label them as such.
