divmod-users team mailing list archive

[Laurens Van Houtven <_@xxxxxx>]

On Sun, Nov 4, 2012 at 8:08 PM, Tristan Seligmann
<mithrandi@xxxxxxxxxxxxx>wrote:

> Did you mean the "stored" callback? "activate" is invoked every time
> the item is loaded from the database.
>

You just found a bug in my code :)


>  > I would also like to log *changes* for some stuff. I'm not entirely
> sure yet
> > if this is even a solvable problem (for example, what happens across
> schema
> > changes?), or which
>
> The "committed" callback is invoked when a transaction is committed in
> which the item was modified; unfortunately you no longer have access
> to the old data by the time that callback runs. Also, any attempt to
> modify the database from the committed callback will cause the
> transaction to roll back, so you'd need to do that asynchronously.


Yes, I had been looking at that.


> I think as far as schema upgrades go, the new version of the item will
> have stored() invoked on it as if it were a completely new item, but I
> haven't tested this, or even looked at the code.
>
> Also...
>
> > s = Shield(store=myStore, value=1)
> > s.value = 10
> > s.value = 5
>
> I assume you actually meant something like:
>
> ###
> s = Shield(store=myStore, value=1)
>
> def _t1():
>     s.value = 10
>
> def _t2():
>     s.value = 5
>
> myStore.transact(_t1)
> myStore.transact(_t2)
> ###
>

Do regular argument assignments not invoke transactions or the
``committed`` callback?

If that's the API, that might actually be better: instead of logging every
change I get to be explicit about which ones I want to log. I could have an
API something like:

loggedTransact(store, transactFunction)

... except with a less terrible name.

The prototype for this could just get all the current stored attributes +
values, then run the transaction, then get the values again and log the
different ones.


> --
> mithrandi, i Ainil en-Balandor, a faer Ambar
>



-- 
cheers
lvh