Thread: [SQL-CVS] [ sqlobject-Bugs-1152199 ] "default" options override explicit attribute set
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
From: SourceForge.net <no...@so...> - 2006-02-09 16:07:32
|
Bugs item #1152199, was opened at 2005-02-26 07:12 Message generated for change (Comment added) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1152199&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: General Group: SQLObject from repository >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Jamie Wilkinson (jaq37h) Assigned to: Nobody/Anonymous (nobody) Summary: "default" options override explicit attribute set Initial Comment: I traced this behaviour to the patch at revision 425 in the repository; at rev 422 it works, and at 425 it doesn't. My object gets its 'location' attribute set, and the function _set_location reads the file at that location and sets a few other attributes within that function. The behaviour I'm seeing is that these attributes are being set during the function, but when the object is referenced later, the default value (as specified when the column is defined) is returned. There's a short example attached, that's slightly contrived to demonstrate the structure of the object, but runs here. The output of such a program at rev 425 is None and at 422 is "a string" ---------------------------------------------------------------------- >Comment By: Oleg Broytmann (phd) Date: 2006-02-09 19:07 Message: Logged In: YES user_id=4799 The test.py works now with SQLObject 0.7 so I consider the bug resolved even without the patch 1338764. ---------------------------------------------------------------------- Comment By: Cody Casterline (codyc) Date: 2005-10-26 03:47 Message: Logged In: YES user_id=1367914 I've confirmed this bug, and it looks to be caused by the order of operations in SQLObject.set(self, **kw). _create() passes default values to set() in **kw. set() sets "plainSetter" columns. set() sets "extra" (_set_*) columns. THEN set() does: self._SO_createValues.update(kw) ... overwriting all of the calculated values just set in the "extra" columns block. I fixed this on my end by removing the dict.update(), and placing self._SO_createValues[name] = dbValue; in the "plainSetter" block. I haven't submitted it as patch because I'm not sure if this breaks anything else. Maybe someone more familiar with the code will know. :) ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-08-10 17:22 Message: Logged In: YES user_id=4799 You've touched a known problem with setters. Avoid setting setters' values in constructor. Instead update them after the objecthas ben created: t = test(location="") t.location="some/path" Now your program works. ---------------------------------------------------------------------- Comment By: Jamie Wilkinson (jaq37h) Date: 2005-06-22 10:51 Message: Logged In: YES user_id=440958 Ok, I hunted down my test code and I've reattached it, and this time I'm sure I've attached it properly :-) I've modified it a bit too, it'll print out the result of the test. I called it like so: PYTHONPATH=.:SQLObject python test.py with a fresh svn checkout, and again with a checkout at revision 421. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-01 16:42 Message: Logged In: YES user_id=4799 Please reattach the test. And don't forget to mark the "Check to Upload and Attach a File" checkbox! (-: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1152199&group_id=74338 |