Re: [SQLObject] Temporary Objects (I'm going in!)

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

Ok, here's my current thoughts on TempObjects/Transactions:

First, whether the external interface is a Transaction object that you
add objects to or not (Brad's suggestion):

> from Transaction import Transaction
> from invoicing import Client
> t = Transaction()
> c = Client(1)
> t.insertObject(c)
> c.address1 = "100 New Street"
> t.saveChanges()

... it seems to me the changes to SQLObject are still the same as my
initial suggestions (Object.temp(), Object.persist()): ie,
t.insertObject(c) needs to call something equivalent to c.temp() so
that it no longer does updates, and t.saveChanges() needs to call
c.persist().

Also, i've seen very little suggestion for an alternate way to make a
Temp *new* object within a Transaction. You need to a way to specify
"create a temp object" as opposed to "create an object then add it to
this Transaction". In general new objects make things much messier,
with the issue of fake IDs needing to updated when
persisted/committed. Again, this is regardless of whether the
metaphor is transactions or tempobjects.

I am in complete agreement with Ian over "Stores" vs "Objects". I
don't want stores; this biases my thoughts on Transaction objects, as
they are explicit temporary stores.

Now, an also seemingly functionally equivalent would be Ian's
TempConnection idea, although I'm not sure I like the interface/look
of needing to pass in an alternate connection for each tempobject. In
general, I want tempobjects to be created and used just like they
were a regular SQLObject, except that they need to be
persisted/committed. However, I think this might be a clean
*internal* implementation for my concept of temp objects: when an
object becomes temp (added to a transaction, or explicitly), it just
swaps it's connection for a TempConnection. Hmm....

So here's my plan of action: implement .temp() and .persist() (I'll
call it .commit() if it makes people happier :) within SQLObject.
This will allow the concept of transactions to be implemented
completely independent of database support, if so desired.

Semantics:

1. temporary versions of an SQLObject will not be visible to any other
connection (ie, unless you have a python-side reference to the
object, it doesn't exist.)

2. temporary versions of an SQLObject can reference either other temp
objects or real objects. Joins queried on a temp object will return
possibly a mix of real and fake objects. The question here is, do we
return temp versions of the real objects? tempPerson.employees, do
something with the employee objects, presumably (from a transaction
perspective) those changes are only saved if the tempPerson is
saved... getting messy....

3. this leads to: real objects can never reference a temp object
without becoming temp themselves. I think this is the way to go, but
it leads to the final mess

4. does persisting any object persist all temp objects it touches?
This makes sense from the example above: create a tempPerson, start
adding temp employees to it, I'd like to simply persist tempPerson
and have it handle the rest. but does it work the other way (persist
one of the employees, and the whole tree/graph is persisted)? Should
there be an alternate way to persist just one? (In the context of a
transaction this becomes particularily important: when do things I
didn't explicitly add to the transaction but that are changed via
join/FK get persisted?)

That's enough thoughts for now. I'd appreciate comments, but I think
it just need to implement something and see how it plays..

- Luke