Re: [SQLObject] Using SQLObjects without database connectivity.

[Luke O. <lu...@me...>]

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