[boost] Re: persistence

[Chuck Messenger]

I think a persistence library for Boost would be fantastic.  I belive 
your schema approach -- compiling a schema into C++ code -- is the right 
one.  Some thoughts on requirements for an ideal C++ persistence library:

* use an XML schema, but some schema information, perhaps in another
  file, support C++ specific issues (e.g. does the data go into a list
  or a vector?)
* support both XML and binary data formats

* support both native-only (useful for IPC) and cross-platform formats

* support for "integrated header files" -- that is, rather than
  generating a C++ header, it should be possible to use an existing one
  (allowing you to customize it).
* support for complex data structures, including recursive structures.
  It should be possible to re-establish pointers, in other words.
To me, that would be the holy grail.  It should probably be developed 
like the thread library, though -- start with core capabilities, then 
build on it over time.

I've love to take a gander at your code...

    - Chuck Messenger

Scott Woods wrote:
Hi,
Is anyone interested in a persistence mechanism? Rather than dumping a bunch
of doc+code and finding that its just inappropriate, here is some summary
stuff.
Technique uses info available in a variant to manage the type-safe transfer
of
data between an application and some external storage. It can be
characterized
as a replacement for the windows registry or unix profiles. The technique
has
following properties;
* generic - load and save operations are templates
* portable - library and data are not platform dependent
* standard types - bool, integer, float, string, etc
* complex types - fixed dimension arrays and variable dimension vectors
* user-defined types - records (a set of members of any type)
Simplest usage involves "hand-forming" the variants. This is a bit
long-winded
(and error-prone) so a "compiler" has been developed. This accepts a
"schema"
conforming to a grammer and outputs a set of C++ classes (cpp and header).
The application can then derive application classes.
Given an application class "alarm_monitor" the schema might look like;

record sensor_signal {   // Generated by raising the signal on an alarm
sensor
 time when     // Instant of detection
 string line     // Expanded text
 void detail[]
}
record monitor_store {   // Persisted image of a monitored sensor
 integer number    // Unique id
 integer status    // Currently
 sensor_signal log[]   // Rolling log of signals
 integer ring_count   // Signal count since last ringing transition
}
The application would derive "alarm_monitor" from "monitor_store" and a
minimal
ctor might look like;
alarm_monitor::alarm_monitor( const alarm_sensor &sensor ) :
{
    try
    {
        // Recover the previously saved image of "this"
        typed_load_file file( sensor.name );

        load( file.begin(), *this );
    }
    catch( typed_memory_not_found & )
    {
        // No previous image. Set the members of "this"
        // to reasonable defaults and save an image
        number = sensor.number;
        status = monitor_ready;
        ring_count = 0;
        log.clear();
        typed_save_file file( sensor.name );

       save( file.begin(), *this );
    }
    // Resume normal operation
}
Hope this is enough info. Code is currently getting a good workout (part of
beta
in a 24x7, server-type product). Example above is "para-phrased" to keep it
short and to remove some confusing coding standards.
Thanks,
Scott


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost