Boost logo

Boost :

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:

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at