Thread: [SQLObject] Re: Subway tutorial and sqlobject
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
From: Ian B. <ia...@co...> - 2005-02-17 17:42:13
|
Justin Shacklette wrote: > For all you lucky dogs that don't have my problems with sqlobject: > > After some more investigation, is is actually MySQL-python that is the > source of my problems as deelan suggested. In the latest version of > MySQLdb (1.2.0), there is the method Binary in __init__.py: > def Binary(x): > from array import array > return array('c', x) > As far as I can see, this method operates on all data returned from > mysql BLOB columns, and returns an array. Any versions of MySQL-python > with this method should throw the same error that I'm seeing, because > sqlobject does not handle objects of type array. Reading in the > comments posted under deelan's MySQL-python bug link, the work-around > given by the MySQL-python team is totally bogus. They said you should > edit __init.py__ and manually put FIELD_TYPE.BLOB under STRING. > > This Binary method is present in MySQL-python version 1.2.0, 1.1.10, > 1.1.9, but back in MySQL-python 1.0.1 there is a different body that > just returns a simple string, not an array: > def Binary(x): return str(x) > > I claim: > 1. If your version of __init__.py returns an array > 2. If FIELD_TYPE.BLOB is under BINARY (also in __init__.py) > 3. Then you will see my error in sqlobject. > If this is not the case, then I'd really like to know what's going on > in your sqlobject's converters.py. > > In site-packages/sqlobject/converters.py, I have inserted a print > statement: > ---------- > def sqlrepr(obj, db=None): > try: > reprFunc = obj.__sqlrepr__ > except AttributeError: > converter = lookupConverter(obj) > print "converter=%s obj=%s" % (converter,obj) > if converter is None: > raise ValueError, "Unknown SQL builtin type: %s for %s" % \ > (type(obj), repr(obj)) > return converter(obj, db) > else: > return reprFunc(db) > > If I add the print statement and re-run my output the original > sqlobject test program, I get: > ---------- > converter=<function IntConverter at 0x00962BF0> obj=1 type=<type 'int'> > row=<Todo 1 title='Trash' description='Take out the trash on Thursday > night.' done=0> > converter=None obj=array('c', 'Take out the trash on Friday night.') > type=<type 'array.array'> > Traceback (most recent call last): > ..barf.. > ValueError: Unknown SQL builtin type: <type 'array.array'> for > array('c', 'Take out the trash on Friday night.') > > So it is clear that sqlobject (ver 0.6.1 and the latest SVN) can not > handle objects of type array. My sqlobject fix is to modify the > StringLikeConverter method in converters.py to also handle the array > type: > ---------- > from array import array > def StringLikeConverter(value, db): > if type(value) == type(array('c','')): > try: > value = value.tounicode() > except ValueError: > value = value.tostring() > > if db in ('mysql', 'postgres'): > for orig, repl in sqlStringReplace: > value = value.replace(orig, repl) > elif db in ('sqlite', 'firebird', 'sybase', 'maxdb'): > value = value.replace("'", "''") > else: > assert 0, "Database %s unknown" % db > return "'%s'" % value > > registerConverter(type(""), StringLikeConverter) > registerConverter(type(u""), StringLikeConverter) > registerConverter(type(array('c','')), StringLikeConverter) > > This should make things work regardless of what version of MySQL-python > you are using. Thanks for following through with this. In this case, I think the answer would be to create a separate array converter, which in turn called StringLikeConverter, but that's just a minor detail. Is there a reason you use value = value.tounicode()? It seems like array objects are typically binary, and so they should be translated to 8-bit strings, not unicode...? Of course, MySQL is messed up, because you have to use BLOB to avoid case-insensitive comparisons. How that fits in to it all I'm not quite sure. UnicodeCol should still produce unicode regardless, as it doesn't depend on any database unicode support. > I'm sorry this whole thread is way off topic, but I believe that the > power of Subway is 'the glue' part from the homepage. There are going > to be some issues integrating all these great packages into a polished > RoR-style stack. But if Subway wants the polish, then it's fork (see > the Package forking thread) or battle these component package issues. -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |