|
From: Ian B. <ia...@co...> - 2004-03-07 23:42:29
|
On Mar 7, 2004, at 12:47 PM, Chris Gahan wrote: > "Peter Gebauer" <pe...@fs...> wrote in message > news:20040307163700.GA1776@coke... >> Many times I want to use SQLObjects as regular data structures, fill >> them >> with data and manipulate that data, but without having to save the >> data to >> the backend. The best thing would be to have a switch in the SQLObject >> telling it when and when not to be database consious. >> >> Or, maybe a small add-on that will make a non-database conscious >> object of >> an SQLObject and populate an SQLObject from a non-database concsious > object. >> >> Has anybody written anything like this already? > > Well, what I did was add .acquireLock() and .releaseLock() functions > to the > SQLObject subclass I made which would adjust and check the "locked" and > "locktimeout" variables. Then I added a function to SQLObject.py called > .values() which returns a dictionary of all the table attributes (it > gets > the attributes the same way that .__repr__() does). > > It's not a very general purpose solution though. I like the idea of > having a > kind of "update object" which looks like an SQLObject, and can be > shoved > back into the database when it's finished being updated. It would be > especially handy if it was picklable, so that it could be used as a > Webware > session variable. > > Hmmm... Ian? What do you think? :) It's pretty complicated when you start to think about it. Some of the stuff I proposed for 0.6 is along these lines. I've thought it through a few different ways, but I haven't felt comfortable about a real solution -- how to handle objects that aren't in the database yet, or aren't associated with a connection at all... how to deal with references among these objects... it's pretty challenging. Pickleability is fairly reasonable right now (so long as you aren't using transactions, at which point pickle is unlikely to work conceptually -- at least until you have transactions that are more abstract than a DBAPI connection object). Anyway, it's just a matter of implementing __getstate__ and __setstate__. The only information you should need in the state is the ID and perhaps a connection identification, though you could leave out the connection in most cases (since the class will already have an associated connection). The connection would be easier with SQLObject trunk, because we have URIs for connections that makes them pretty easy to identify and serialize. Unfortunately, __setstate__ isn't really the API we'd like to have -- in that case we already have an instance and we need to put it into working order. But we might already have an instance in the process, and we don't want to create another. This is where 0.5 is easier, because we can just use __getinitargs__ -- I think it might be best to extend 0.6's __init__ so that (with the right invocation) it can act like 0.5's (i.e., get an object instead of creating a new object). Anyway, pickle shouldn't be too hard. -- Ian Bicking | ia...@co... | http://blog.ianbicking.org |
