A lazy-committing database object with curry?

[Robert Brewer]

Tim Lesher wrote:
> I'm writing a database helper class that represents records in a SQL
> database as objects.  I want to be able to instantiate the objects
> (from the database), play with their values locally, then lazily
> commit the changes all at once (via an explicit commit call).  Other
> than the call to Commit(), I don't want clients of this class to have
> to think about the fact that there's a database behind it all--there
are
> some interesting and non-obvious dependencies on the particular values

> that are committed together, and I want to hide that in the Commit()
call.
> 
> 8< curry code snipped >8
> 
> Are there any pitfalls to doing this?  Am I being dazzled by the shiny
> new toy that is currying?  Is there another simple solution, or a
> refinement of this one, that I'm not seeing?

I have to admit I've never thought of using currying for that. My usual
approach in such a situation is to have an additional object attribute
which acts as a flag for whether or not the object is "finished".
Commit() could then be called at any time, but it won't actually do
anything if instance.finished is False. It reads clearer to me than all
the currying:


class SomeRecordType(object):
    def __init__(self, title, description):
        self.title = title
        self.description = description
        self.finished = False

    def Commit(self):
        if self.finished:
            Do_database_commit(self)

foo = myDb.LookupTitleRecord('some title')
foo.description = 'bar'
foo.Commit()             # not updated in the DB yet
foo.finished = True
foo.Commit()             # now updated in the DB

Incidentally, this allows other threads to do the Commit calls for you,
on a schedule. So your client code wouldn't need to call Commit() at all
if the app is persistent.


Robert Brewer
MIS
Amor Ministries
fumanchu at amor.org