|
From: SourceForge.net <no...@so...> - 2006-09-07 16:03:12
|
Bugs item #1463974, was opened at 2006-04-04 12:20 Message generated for change (Comment added) made by ptrck You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1463974&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 release (specify) >Status: Open Resolution: Wont Fix Priority: 5 Submitted By: Patrick Coleman (ptrck) Assigned to: Nobody/Anonymous (nobody) Summary: Column name collides with internal method Initial Comment: Hi, My database has a column 'expire' in a certain table. It appears that when SQLObject calls expire() (line 778, dbconnection.py) on a cache object from that table, rather than calling the expire method to expire the object from cache it actually returns the value from the 'expire' column, which being a Long of course isn't callable, resulting in the attached exception. I propose that internal methods used by SQLObject use names that are unlikely to collide with column names (perhaps by prepending __SQLObject__ or similar), and that these internal names be documented so database designers can avoid using names that may collide. SQLObject is SQLObject-0.7.0-py2.4, as shipped with Turbogears 0.8a3-py2.4. Thanks, Patrick -- http://www.labyrinthdata.net.au ---------------------------------------------------------------------- >Comment By: Patrick Coleman (ptrck) Date: 2006-09-08 00:03 Message: Logged In: YES user_id=646977 Thanks for the suggestion - I'll give it a try. However the problem, as I'm sure you realise, is *not* that the column 'expire' in my database is inaccessible. The problem is that *all transaction support* in SQLObject completely breaks when a column called 'expire' exists anywhere in the database. Specifically, rollbacks don't work at all which more or less defeats the point of transactions. The result for end users is that when they install SQLObject on an existing database with a column called 'expire', SQLObject breaks inexplicably. There is no documentation of this behaviour, and so most people are just going to conclude that SQLObject is broken, rather than performing this workaround. I agree that expire is a public method, but I feel that perhaps the current behavior should be modified so that: - SQLObject noticies a column the same name as a public method and throws a meaningful error; or - SQLObject noticies a column the same name as a public method and overrides the public method with the column method (but internally continues to use the non-column public method, so that eg. transactions do not break as they do now); or - SQLObject notices a column the same name as a public method and refuses to publish the column method. --Patrick ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2006-09-07 23:43 Message: Logged In: YES user_id=4799 But .expire is not an internal method - it is perfectly valid public method. Now think you read or write inst.__SQLObject__expire() in some code instead of inst.expire()! The workaround would be to made the column's name and db anme different: local_expire = DateTimeCol(dbName="expire") Now you can access inst.local_expire (or whatever you name it) and call inst.expire(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1463974&group_id=74338 |
