Re: [boost] [persistent] Persistent library preview

Subject: Re: [boost] [persistent] Persistent library preview
From: Peder Holt (peder.holt_at_[hidden])
Date: 2010-01-07 05:14:46

2010/1/5 Stefan Strasser <strasser_at_[hidden]>

> Hi,
>
> Am Monday 04 January 2010 23:13:35 schrieb Peder Holt:
> > >From the documentation it seems that the library supports some form of
> >
> > 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.
>
> there is an example of that in Tutorial 3 but maybe I should add a simpler
> one
> before going into the details of concurrent transactions:
>
>
> void f(loc<pers_type> l){
>
>  l->name="John";
>  {
>    transaction tx;
>    l->name="Mike";
>    //tx.commit(); //this call is omitted
>  }
>  assert(l->name == "John");
>
> }
>
> usually, the call to "commit" is omitted because of an exception, so this
> helps you to ensure data consistency and "strong" exception safety
> guarantees.
>

Would you consider to add this to the library?

The difference would be that the persistent storage could store multiple
versions of each object.

Looking at it naively, one transaction could be considered a single history
fragment.
Each history fragment contains
- a reference to the next/previous history fragment.
- a reference to all objects that was modified in this transaction
- a reference to all objects created/deleted in this fragment.

All objects that are loaded to memory in a transaction are candidates for a
status as modified.
If an object is only loaded for read only access, it should not be set as
modified.
Do you think this method is feasible to implement in your library?

In our CAE application, we have implemented unlimited undo/redo as a
combination of the above technique and an implementation of:
http://www.codeproject.com/KB/cpp/transactions.aspx
plus some other techniques.
Currently all our objects are loaded in memory always, so we need a library
to limit the number of objects that are loaded while preserving the
undo/redo capabilities.

> >
> > Also, can you describe the caching mechanism?
> > How much control do the user have over how much memory he can afford to
> use
> > for caching objects in memory?
> > Is it possible to control cache size per type?
>
> a cache sweep is (almost) linear to the number of objects removed from the
> cache in the sweep, so caches can be large.
>
> 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?

>
> > A final question:
> > I have an application that saves analysis results for a given analysis as
> > an HDF5 file. http://www.hdfgroup.org/HDF5/
> > This HDF5 file initially contains only input to the analysis. The HDF5
> file
> > is then fed to another program which modifies it and stores back results.
> > 1. Is it possible to to make boost.persistent write its data to an HDF5
> > file?
>
> although theoretically possible (see "Extending Boost.Persistent") I don't
> think I would advise to do so. that'd be like you decided you wanted to use
> MySQL to process some data, but instead of exporting the data when you're
> done you decide to write a MySQL storage backend that can write to your
> file
> format.
>
>
Ok. I won't go down this path then :)

Regards
Peder