On Thu, 7 Oct 2004 21:20:37 +0900, Brian Candler wrote

> I'd like a database object mapping framework to remember the 'old' 
> values of properties at the time an object was read, and perform 
> safe atomic updates.
> 
> e.g. sample
> +---+-------+------+-------+
> |id |  a    |  b   |  c    |
> +---+-------+------+-------+
> | 1 | hello | Ruby | world |
> +---+-------+------+-------+
> 
>   obj = $db.get(1)       # a="hello", b="Ruby", c="world"
>   ...
>   obj.a = "goodbye"      # still remembers old_a = "hello"
>   obj.b = "Perl"         # still remembers old_b = "Ruby"
>   obj.save
> 
> generates:
> 
> (1) lax
> 
>   UPDATE sample SET a='goodbye',b='Perl' WHERE id=1 AND
>     (a='hello' OR a='goodbye') AND (b='Ruby' OR b='Perl');
> or
> (2) strict
> 
>   UPDATE sample SET a='goodbye',b='Perl' WHERE id=1 AND
>     a='hello' AND b='Ruby';
> 
> and raises an exception if the row processed count = 0. That stops
> simultaneous updates stamping on each other. The 'strict' version is 
> useful for counters, sequences etc.

That's an interesting suggestion, as it gives one a defense against some 
external process coming in and changing things unexpectedly.  Putting this 
on my todo for Kansas!
 
> These 'old' properties might also be useful for object-level 
> transactions, without serialisation as 
> ActiveRecord/Transaction::Simple does.

In Kansas, it keeps each old value within the context of a transaction, but 
after the transaction is committed, the old values go away.  I don't provide 
any interface, however, for actually access the old values at any time.  Can 
you elaborate more on ways that you would see the old values being used?  
This is quite educational.

As for object-level transactions without serialization, I'm not sure about 
AR, but with Kansas one can set a read-only attribute on data objects, and 
can direct a query to return the data with the objects already in a read-
only state.  While read-only is on, changes to the object will not get 
serialized back to the db.


Thanks,

Kirk Haines