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