Re: [SQLObject] Transaction Implmentation

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

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

That's what it seemed like. Cool.

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

That was just for my sake as it came together, they could easily be
combined.

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

Hmm. yep, that's really all addToTransaction is, and _persist is just
copyBackToClassConnection, which could be the default arg behavior
for copyToConnection.

The one thing I've found handy with the Transaction idea is that it's
an obvious grouping mechanism for a collection of temp objects.
Anyways, the interface you suggest above is very compatible with how
I've built things, so long as we keep
MemoryTransaction.commit()/rollback().

Also, I think it would be good to simplify things somewhat inside
MemoryTransaction to only have a single persistentConnection, as
opposed to tracking per-class connections (which are likely all the
same). Especially since I had to ignore the per-class thing for
joins, where I don't know what class it's coming from. :) Only thing,
I'd probably make it so it'll transparently pick up the connection
from the first object added to it, as opposed to a necessary explicit
part of __init__. (When I'm writing user-side SQLObject code, I never
have direct access to the connection object being used, unless we
want to promote explicit inst._connection access.)


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

Yes, I like the name MemoryTransaction actually. Although it's not
particularily clearer what it does...

> 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 problem here (why I needed to turn off caching explicitly) was
that copyToConnection first created a new instance using the
old/persistant connection, which we didn't want cached. Now, if we
ensure that MemoryTransaction already has a persistantConnection
(either by setting it explicitly in copyToConnection, or in its
__init__), then this requirement can go away, and behave as you
suggest. Sounds good. I don't care whether MemoryTransaction's cache
picks it up or not, as MemoryTransaction can't currently be used for
a primary connection type anyways.

A side note: I'm having MemoryTransaction use negative object IDS for
newly created temp objects to distinguish and avoid clashes. Anyone
forsee a problem with this? I can't recall seeing a database that
used negative SERIAL/AutoIncrement fields, but I suppose it could
happen...

Let me merge these ideas together, I'll throw up a new email in the
morning. Summary: simplify to single MemoryTransaction class with
single persistantConnection, and single copyToConnection method in
SQLObject. Alrighty.

- Luke