Thread: [SQLObject] Global column conversion based on type?
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
From: kgi <ia...@gm...> - 2005-09-09 16:24:45
|
Hi there. I'm currently developing a system that uses XML-RPC and SQLObject extensively. One of the biggest drags is that SQLObject's datetime type is python's datetime, whereas xmlrpclib requires that it be passed xmlrpclib.DateTime objects (which is a much dumber entity than datetime). At the moment I'm having to manually convert all the pertinent accesses by hand, but it would be Really Cool if this could be done automatically[1]. I know about the Magic Attributes (_get_fooBar() and _SO_get_fooBar()), but these depend on the *name* rather than the *type* of the column. How easy would it be to add a generic type translation hook based upon column types? Now, I had a poke around the code and, whereas I found some of it a little daunting, it looks like the from_python/to_python methods in the validator classes in sqlobject/col.py are the right sort of place to start hacking. However, I'm not sure where I should add the hook that tells SQLObject whether it wants DB dates converted to datetimes or xmlrpc.DateTimes. Can anyone give any guidance or advice? Cheers, Ricky [1] Another option, of course, would be to modify xmlrpclib to accept other date types, but I think I'd prefer modifying SQLObject as it might have other benefits elsewhere in the project. |
From: Oleg B. <ph...@ma...> - 2005-09-09 16:51:44
|
On Fri, Sep 09, 2005 at 11:43:49PM +0300, kgi wrote: > I'm currently developing a system that uses XML-RPC and SQLObject extensively. > One of the biggest drags is that SQLObject's datetime type is python's > datetime, whereas xmlrpclib requires that it be passed xmlrpclib.DateTime > objects (which is a much dumber entity than datetime). Create your own clumn type. Copy code from col.py (DateTimeCol and related classes) and modify them to suite your needs. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Ian B. <ia...@co...> - 2005-09-09 16:54:01
|
kgi wrote: > Hi there. > > I'm currently developing a system that uses XML-RPC and SQLObject extensively. > One of the biggest drags is that SQLObject's datetime type is python's > datetime, whereas xmlrpclib requires that it be passed xmlrpclib.DateTime > objects (which is a much dumber entity than datetime). xmlrpclib has ways to convert objects, I believe, though it's a slight pain in the butt to actually extend. Something with extending Unmarshaller.end_dateTime, and Marshaller.dispatch. You don't want to use stupid xmlrpclib.DateTime objects in your code anyway. > At the moment I'm having to manually convert all the pertinent accesses by > hand, but it would be Really Cool if this could be done automatically[1]. > > I know about the Magic Attributes (_get_fooBar() and _SO_get_fooBar()), but > these depend on the *name* rather than the *type* of the column. How easy > would it be to add a generic type translation hook based upon column types? > > Now, I had a poke around the code and, whereas I found some of it a little > daunting, it looks like the from_python/to_python methods in the validator > classes in sqlobject/col.py are the right sort of place to start hacking. > However, I'm not sure where I should add the hook that tells SQLObject > whether it wants DB dates converted to datetimes or xmlrpc.DateTimes. > > Can anyone give any guidance or advice? You can do this, probably with a DateTimeCol subclass, a little like: class SOXmlRpcDateTimeCol(col.SODateTimeCol): def createValidators(self): return col.SODateTimeCol.createValidators(self) + [XmlRpcDateTimeValidator()] # I can't remember the exact methods here: class XmlRpcDateTimeValidator: def to_python(self, datetimeobject, state): return xmlrpclib.DateTime(datetimeobject.timetuple()) def from_python(self, xmlrpcdatetime, state): return datetime.fromtimetuple(xmlrpcdatetime.value) class XmlRpcDateTimeCol(col.DateTimeCol): baseClass = SOXmlRpcDateTimeCol All untested of course. If you go down this route and get something working, please respond with the result. -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |