A lazy-committing database object with curry?

[Tim Lesher]

Jp Calderone <exarkun at intarweb.us> wrote in message news:<mailman.514.1074539232.12720.python-list at python.org>...
> On Mon, Jan 19, 2004 at 08:45:45AM -0800, Tim Lesher wrote:
>   Are you sure?  How will the initial values be committed to the database,
> if you don't catch them in the modifications dict?  I guess you might be
> handling initial values somewhere else, in code you didn't post...

Yes... this class will only be working on rows that already exist in
the database--in other words, it only has to cope with updates and
deletes, not inserts.

>   Nift.  You surely don't use the full capabilities of currying here, but
> you are incurring a double function call overhead on every setattr now. 
> Here's another way to do it:
> 
>       def makeModificationFunctions(name):
>           def modget(self, value):
>               try:
>                   return self.__modifications[name]
>               except KeyError:
>                   return self.__dict__[name]
>           def modset(self, value):
>               self.__modifications[name] = value
>           return modget, modset
>       title = property(*makeModificationFunctions('title'))
>       description = property(*makeModificationFunctions('description'))

Aha.  This is what I was really looking for.  I tried it with lambdas
at first and got bitten by the expressions-only limitation.  Coming
from a C++ background, I keep forgetting about local functions...

>   Of course, you can go one step better and use a metaclass:

Wow.  That's even shinier than the currying.

>    This can be just "if self.__modifications:"

I know... explicit better than implicit and all.

>   One possible problem is failed commits.  If you're doing commits
> transactionally, and the transaction fails, your in memory objects will
> retain their now-inconsistent values while the database remains unupdated. 
> If you're not using transactions.. well that's a whole other problem :)

Yep, failed commits are handled in the 'snipped' piece of code when
they're handled at all--initially this is running against a
transactionless database, but the place is there to handle
transactions--that's why I don't clear the modifications until after
the update is made.

>   You may want to look at xsdb and atop.  Neither uses SQL, but both have
> developed pretty heavily on some of the ideas you're tinkering around with.

Thanks; I will.

-- 
Tim Lesher
<tim at lesher.ws>