|
From: SourceForge.net <no...@so...> - 2007-09-15 12:30:04
|
Bugs item #1768433, was opened at 2007-08-06 07:01 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1768433&group_id=74338 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: SQLObject release (specify) Status: Closed Resolution: None Priority: 5 Private: No Submitted By: azav (azav) Assigned to: David Turner (novalis_dt) Summary: Versioning broken in 0.9.1 Initial Comment: The versions table uses the same constraints as the original table, so having for instance a unique column in a table will raise a DuplicateEntryError when a second version with the same name is created. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-09-15 05:29 Message: Logged In: NO Ahh.. now i see why my first solution only solves half the problem. azav is right in his example with foreign keys... So forth a versioned row holds a foreign key to another table, that constraint is still present. When using a database engine enforcing foreign key constraints a foreign key of an old row cannot be deleted as it might still be referenced with a no delete policy. For this reason rows may be stuck in a table due to old versions of rows from other tables still reference them. A simple solution would be to convert foreign key columns to simple int columns, thereby having no constraints. This way older versions of a table holds no foreign key constraints on other tables. However this may prevent versioned tables from being restored to previous versions so forth the referenced field has been deleted, as this could break a notNone constraint. As i see it the possibilities is to store all foreign key data in the version table too (impractical and possibly impossible), or accept this flaw in the system... Any good ideas? If you can suggest a solution ill gladly post an implementation example. ---------------------------------------------------------------------- Comment By: David Turner (novalis_dt) Date: 2007-09-10 13:59 Message: Logged In: YES user_id=83137 Originator: NO I fixed this in SVN (unless the foreign key thing turns out to be a problem) ---------------------------------------------------------------------- Comment By: David Turner (novalis_dt) Date: 2007-09-10 11:16 Message: Logged In: YES user_id=83137 Originator: NO I think the old versions ought to have the same foreign key constraints. Why does this cause problems? ---------------------------------------------------------------------- Comment By: azav (azav) Date: 2007-09-10 01:43 Message: Logged In: YES user_id=1861531 Originator: YES This only fixes part of the problem. For instance, version tables will still be created with the foreign key constraints of the original table. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-09-07 13:37 Message: Logged In: NO I stumbled across the same problem. As constraints are directly copied to version tables, each version of a row needs to hold new values in all unique columns. This may not be acceptable to all applications. In order to fix this a minor change can be made to the file /sqlobject/versioning/__init__.py. You merely need to add a few lines. Heres the result from a diff between the original and my changed version: 48c48,51 < columns[column] = defi.__class__(**defi._kw) --- > kwds = dict(defi._kw) > for kw in ["alternateID", "unique"]: > if kw in kwds: del kwds[kw] > columns[column] = defi.__class__(**kwds) I dont know if this is the way the sqlobject authors would do it, but it seems to work. Hopefully it will result in a faster patch :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1768433&group_id=74338 |
