Mike Driscoll wrote: > > Well, I did the fake id column because SA was throwing an error on a > the reflected table since it didn't have a primary key defined. I > think I may have found a workaround though.
>From SA's point of view, the primary key just has to be a set of columns that uniquely identify a row in the database. It doesn't explicitly have to be defined as a primary key in the database. The reason for this is that if you retrieve an object (a row) from the database and modify it, there is no way to save those changes back to the database unless you can uniquely identify that row, so you know what to put in the WHERE clause of the UPDATE statement. If there really isn't a set of columns that uniquely identifies a row in the database, and you only want read-only support, you might be able to tell SA that the primary key is made up of all the columns in the table. However, if there are any duplicate rows in the table, SA will only return a single object for those rows because it has no way of knowing that they are different. If you do have duplicate rows, you might be better working with the SQL-only layer of SA, rather than the ORM. Simon --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
