Re: [SQLObject] Transaction Implmentation

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

On Mon, 2003-05-12 at 16:26, Luke Opperman wrote:
> (Tried sending this, I guess 70K attachments are just on the edge of
> kosher, so get the file here: http://www.amoebagod.com/SQLObject.zip
> )

Yeah, and I've forgotten the admin password, so I couldn't pass it
through :-(

I don't fully grok the code yet, but from what I see -- it looks like
most of the changes inside methods in SQLObject are probably the right
way to do things even without these transactions.  

Now, I'm still not sure why there's a distinction between
MemoryConnection and Transaction -- they seem like they could be the
same class.

> Well, after finding time, and getting today's CVS, I'm very pleased to
> announce a test implementation of Python-side Transactions for
> SQLObject.
> 
> Interface:
> 
> New exported class 'Transaction' (yes, I know there's already a
> Transaction class in DBConnection, but I couldn't come up with an
> alternate name, and they won't clash for now.)
> 
> Public Transaction methods:
>   t = Transaction()
>   t.commit()
>   t.rollback()
> 
> New methods in SQLObject:
> 
>   a = Class.newForTransaction(trans, ...) same as classmethod "new()"
>   b = inst.addToTransaction(trans) copies inst to the transaction
> (inst remains un-transactioned in this case, although you could do
> inst = inst.addToTransaction(trans) )

With connections:

trans = MemoryTransaction(persistentConnection)
a = Class.new(connection=trans, ...)
# New copyToConnection method, works between any connections...
b = inst.copyToConnection(trans)

The MemoryTransaction (or whatever it is called -- I feel like "temp"
should be the name somewhere)... it also happens to keep track of things
so it can copy objects back on commit.  It seems like a nice orthogonal
feature, because I can imagine copying between connections besides just
transactions.

Perhaps a different name than "connection" will make this feel
conceptually more clear -- *Connection is something of a misnomer, as
that's only a small part of the functionality, and new things like
DBMConnection and MemoryConnection aren't connections.

>   __new__() now takes an additional argument 'useCache' to forcefully
> avoid caching of a specific instance. This is for addToTransaction,
> where we create a clean instance and then switch connections (but
> don't want any record in the class/original connection cache)

Couldn't the connection's cache just be a sort of no-op, to achieve the
same thing?  That is, MemoryConnection's cache attribute just returns
None on .get(), and ignores .put().  The effect is no caching.

>   new() now sets inst._connection = kw['connection'] if a connection
> is passed in. I'm not sure if this will break other expected
> behavior, but it seems reasonable to me.

Yes, that should be in there anyway.

>   RelatedJoin: performJoin, add, remove:  these all now use 'inst'
> argument instead of self.callingClass to get a connection from.
> Again, not sure if this will break expected behavior, but seems
> reasonable to me. (I need this because, along with the previous
> change, I am expecting true per-object connections when I ask for it.
> :)

Yes, sounds right too.

  Ian