On Jan 31, 2006, at 8:45 PM, Karl Guertin wrote:
What are the limitations on primary keys? Do primary keys need to be immutable?
yes, an object gets an "identity key" which is in part based on its primary key identity. if that changes, the ORM will have problems since it is keeping objects in memory that are expected to correspond to the database in a certain way, without that relationship changing.
Does the primary key (explicit or composite) need to have a 1:1 mapping onto rows or can the pk map to multiple rows?
the primary key corresponds to a single row in the table. the single-row identity can have a collection of related rows somewhere else but that single row is a prerequisite.
I'd guess that result rows are directly turned into mapped class instances, but updates and deletes would apply to all rows addressed by the pk. I should probably figure this out by looking at code, but clarification would be appreciated.
Im trying to think what an ORM without a single-row primary key would look like and im not coming up with anything :). if you selected from a table that had the same primary key multiple times, and fed that into a mapper's result processor, the multiple rows would all be aggregated into the same object instance, meaning you effectively would get the first row represented in your object but the rest would be discarded.
------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Sqlalchemy-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
