Re: [SQLObject] Temporary Objects

[Ian B. <ia...@co...>]

On Fri, 2003-04-25 at 16:56, Luke Opperman wrote:
> 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.

Yes, I can see the utility.  I was just doing a project (without
SQLObject) that involved a database, and doing updates and preview,
which would be a pain without temporary objects, so I'm sensitive to the
need.

A lot of ORMs deal with this by having a distinction between the store
and the object.  You create the object, then add it to the store at some
point.  There may also be an explicit way to save the object.  Both
handle the problem, though without any help regarding foreign keys.  But
that's a whole different metaphor from SQLObject, and not one I care
for.

So, I'm thinking about how that would otherwise work... and I'm just not
seeing it.

One way would be to use a different store, like:

tmpConn = TempConnection(__connection__)

p = Person.new(..., connection=tmpConn)
# or...
p2 = Person(5, connection=tmpConn)
# tmpConn fetches from the database, but doesn't save back to it
# so you do stuff with these objects, then...
tmpConn.commit()

Is that a lame interface?  It seems fairly functional, and I can imagine
how it would be implemented, even if connection doesn't seem like the
right term... but that's the way database transactions are already
handled, so I guess it's not so bad.  It still leaves the question of
IDs of objects that haven't yet been added to the database.

> 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).

BTW, _SO_autoInitDone is gone, since objects aren't lazily fetched
anymore (since I wasn't coming up with any use cases).

I'd be interested in adding this to SQLObject itself, so long as it
doesn't mean horribly ugly hacks.  There aren't that many hacks in it,
and I'm hoping to keep it that way :)

  Ian