Re: [SQLObject] Temporary Objects

[Brad B. <br...@bb...>]

On 04/25/03 16:56, Luke Opperman wrote:
> Hey all -
> 
> Ok, I'm going to present a possibly controversial idea. I'd like to
> propose the concept of 'temporary' objects, for use in cases where
> you want to save values (say from a series of web forms) in
> SQLObject-constrained containers (columns, relationships), but don't
> want to persist to the database until the user finishes the process.
> 
> Two use cases: 1. Creating a new temp object, modifying etc,
> eventually persisting to a real SQLObject. 2. Taking an existing
> SQLObject, creating a temp from it, modifying etc, and storing back
> to the original record.
> 
> Hardest part of this: dealing with foreignKeys, on persist keys have
> to be updated from their fake values to the actual new objects' ids.
> 
> Not sure whether to implement this as a helper class to SQLObject
> (that takes an SQLObject on init), or directly in SQLObject.
> Examples:
> 
> 
> Helper class
> ------------
> x = TempSQLObject.new(Person,....)  #just like SQLOBject.new(....)
> x.whatever
> ...
> y = x.persist()  # y is now a real SQLObject of type Person.
> 
> 
> z = Person(23) # existing object
> w = TempSQLObject(z)
> ....
> z = w.persist()
> 
> 
> Part of SQLObject
> -----------------
> x = Person.temp(.....)  # just like .new()
> ....
> x.persist()  # no possibility of keeping temp object; it's real now.
> 
> y = Person(23)
> w = y.temp()
> ....
> y.persist(w)  # or y.set(w) ?
> 
> 
> Any thoughts? My immediate preference is to do it as part of
> SQLObject, it would be very similar to the _SO_autoInitDone flags.
> But makes a rather substantial change to the class for something that
> other people may not need. The TempSQLObject direction keeps more
> separation, but makes interface maintenance more difficult (in my
> mind so far).

Your motives are well-founded, but I don't entirely agree with your
choice of metaphor.

What you're really looking for is transactions.

Something like:

from Transaction import Transaction
from invoicing import Client

t = Transaction()
c = Client(1)
t.insertObject(c)
c.address1 = "100 New Street"
c.telephone = 4045551212
c.fax = 4045551213
t.saveChanges()

the you can do things like:

from Transaction import Transaction
from invoicing import Client

t = Transaction()
c = Client(1)
t.insertObject(c)
c.address1 = "100 New Street"

try: 
    c.telephone = 40455519
except TelephoneErr, err:
    print "Error saving telephone number:", err.value
    t.rollback()
else:
    t.commit()

This kind of interface would not care about whether the backend
persistence is a database, or merely simple files and would provide
the kind of atomicity you're looking for, in a more "classical"
database style.

What do you think?

-- 
Brad Bollenbach
BBnet.ca