|
From: Luke O. <lu...@me...> - 2004-05-13 17:49:31
|
Quoting Peter Gebauer <pet...@st...>: > > myDataStruct = new SomeSQLObject() > .. set some attributes from web forms, store it in a session, etc .. > myDataStruct.save() > > Or similar... :) > > Has anyone implemented a way to do this? A long time ago I wrote something that did this. I'll send you the code if you want, but I can't say how useful it will be. But here's the conceptual path I took. The basic idea was a DBAPI/DBConnection compatible class that stored everything in memory. Tables/values were internally kept as lists/dictionaries. I left out all of the select and create/drop table/column stuff. I guess you might be able to make a case for implementing select, but I didn't need it, and it makes things much tougher (actually have to implement some SQL). Creating new objects in the MemoryConnection was simple, except you don't know what ID to give yet. I used negative ints, to be converted at commit/save time with queryInsertID. Editing an existing object was a matter of creating the object in the MemoryConnection and then doing a _selectInit with the results of the object's previous connection. Joins and ForeignKeys were the real issue: for newly created objects, you need to run through and update any related objects with it's new ID. If a join list is changed for an existing object, now you need to do queries that combine both the existing unmodifed objects (not part of MemoryConnection) and any additions/deletions pending in the MemoryConnection. Basically, newly created/updated intersection records and previously existing deleted records are stored in the MemoryConnection, but most of the results exist in the original connection, perform some set operations to merge the changes. You'll need to have the original connection available most of the time because of that, making it break the seamless appearance of an SQLObject at some point if you need to store to session/retrieve (unless connectionURIs make that feasible; i really need to play with the latest version of SO). I think that's about it. At the time, issues with SQLObject's cache were making it difficult to update existing instances of the objects once they are committed/saved out of the MemoryConnection. I think those are cleared up now: need a way to obsolete all existing instances of an object and make them go back to the cache/database for values. I think that about covers where I went with this. It was functional at one time, but I haven't had a case to use it since. - Luke |
