|
From: SourceForge.net <no...@so...> - 2007-09-07 20:37:19
|
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: Open Resolution: None Priority: 5 Private: No Submitted By: azav (azav) Assigned to: Nobody/Anonymous (nobody) 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-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 |
