Re: [boost] [persistent] Persistent library preview

Subject: Re: [boost] [persistent] Persistent library preview
From: Stefan Strasser (strasser_at_[hidden])
Date: 2010-01-07 05:53:45

Am Thursday 07 January 2010 11:14:46 schrieb Peder Holt:

> > > undo/redo.
> > > Is this the case? And if so, can you give a short code example of how
> > > to use this?
> >
> > there is "undo" by using transactions. however, it is not there to
> > support undo/redo like you see in GUIs, if that's what you meant. once
> > a transaction is committed, it is permanent.
> >

>
> Would you consider to add this to the library?

I'm not sure a storage library is the right place to implement a undo/redo 
queue itself.

the saving of multiple version of an object isn't a problem, a similar 
technique is used already to isolate concurrent transactions.
but you assume that there is a sequential history of transactions and "undo" 
represents going back a step in that history.

but take e.g. a user that changes some data, then changes some preferences of 
the application, which are also stored in the database, and then requests a 
undo of his changes to the data.

the preferences obviously should not be undone. and in other cases not only 
unrelated data like preferences is changed but data that potentially 
conflicts with the "undo" operation. for example:

1. transaction 1, caused by GUI user:
obj->value=5;

2. transaction 2, caused by application without user request:
obj2->value = obj1->value + 1;

3. user requests undo of transaction 1

the library would need to detect this conflict and deny the undo. to 
accomplish that, a lot more information has to be logged than currently is,  
that would not be used for any other use of the library.
e.g. information about read accesses of a transaction (in the example, tx2 
reading obj1 causes the conflict).

so, I think this should be handled by user code. but the library can support 
that. e.g. changesets/patches could be introduced.
after a transaction has committed, you could request a changeset from the 
transaction that does contain all information to undo the changes made by the 
transaction and check for conflicts.
this would also open the door for other use cases than sequential undo/redo.

limitations: the changesets need to be handled by user code (e.g. storing it 
in an undo queue), and e.g. saving the undo queue to disk would not be part of 
the atomic operation(commit) that created the changeset.
so you could loose your undo changeset in a crash but the transaction is still 
in place.

if that is acceptable to your use case and other use cases you can think of 
I'll at it to the "future development" page.
I don't think it's an essential part of such a library and necessary for the 
initial version of it.

but you seem to be experienced in implementing undo/redo so you're welcome 
to draft a public interface for this.
the implementation would be pretty easy I think. the information that 
describes the changes made by a transaction is already available while a 
transaction is running.

> > currently, the size of the cache is only controlled by the number of
> > objects
> > that can be in it. (see Configuring Boost.Persistent )
>
> This covers my needs.
> Is it feasible to implement support for setting the max_cache_size per
> type?

no you can't but I agree that this needs improvement. I'll probably add what I 
described in the last email by the name of "cache_factor" and support limiting 
the number of objects either per type or per group.
by group I mean limiting the overall number of objects in the cache that are 
of type A, B or C.
with each type having its own "group" by default this feature would be a 
superset of limiting per type.
7