[boost] Re: Serialization to relational table

From: Bohdan (warever_at_[hidden])
Date: 2002-11-18 14:36:31

"Vladimir Prus" <ghost_at_[hidden]> wrote in message
news:arb8od$c87$1_at_main.gmane.org...
> Bohdan wrote:
> > I believe that XML can contain any data. But i suspect that
> > XML garbaged with all serialization stuff will be
> >       1. unreadeable
> >       2. difficult to handle automatically (by other programs).
> >
> > So i was thinking about simplifying Object <-> XML serialization.
> >   Recently there were talks about ditto & relational algebra libraries.
> > Also there was message about stl container on disk.
> > As i understand at least some of these libs require special kind
> > of serialization: Object <-> Relational tuple (object-relational mapping).
> > Having such mapping it would be easy to put Relational data to XML.
> > And in this case XML will be very readable.
>
> Wouldn't there be a problem with converting object with variable size?
> How can you store vector<int> in a relational database? I don't see an easy
way.

Relational record field can be of simple type (int, char[n], double) or
it can be other nested table. In your exapmle:
vector< int >        ->
    record
    {
        nested_table_field
        {
            record
            {
                field<int>
            }
        }
    }

>
> > I know this approach has some limitations and doesn't fit very well
> > to serialization library design, but IMHO Object <-> relational tuple
> > conversion would be very useful :
> >     1. store/retrieve object to/from relational tables (in-memory & disk
> > databases).
>
> Do you think that automatic mapping is possible in case of relational
database?

No. Serialization lib also is not automatic. I think user should define mapping
information manually. But if you have only one side object definition (header
file)
or relational dabase schema (DDL) and you want to build other side automatically
than it is possible to create some tool that does it automatically.

>
> Of course, you might have Berkeley DB or something like that, which is
> on disk map<string, string>. But in this case, Robert's serialization
> library would work just fine. And BTW, I'd like to have such thing.

I don't know much about Berkley DB, but it looks like it is not relational
db (record==serialized object ?). It is very limited comparing to fullblown
relational database. But i agree it would be very useful to have something
like that.

>
> >     2. now collection of object can be represented in GUI. Ex: vector<
MyObject
> >
> >        can be viewed and edited by user in some kind of grid.
> >     3. putting/getting relational data to/from XML is much simpler than
> >        object <-> XML serialization.
>
> Consider this code:
>
>      class C {
>      public:
>     int i, j;
>              struct imp;
>              imp* pimp;
>              vector<int> data;
>      };
>
>      vector<C> c;

Do you think that any serialization is possible without information of what imp
type is ?
If you are using pimp idiom than you don't want to show private members.
And you don't want external code to access pimp data. I have doubts if you
can/need serialize any private data at all. If you need - just put serialization
code
in class  method.

>
> How will you convert "c" into a set of tables?

table //vector<C>
{
    record //C
    {
        field<int> i;
        field<int> j;
        fields for pimpl object;  //depends on implementation of imp
        nested_table //data
        {
             record
             {
                  field<int>;
             }
        }
    }
}

I can see it as some kind of "builder" interface:
         - create table <record schema>
         - add field of <simple type>
         - add nested-table field

simple example:
<code>
class A
{
public:
     int                     x;
     char                  y[100];

      static void define_table( builder & b, table& t )
      {
            b.define_field( t,  "X", int_field );
            b.define_field( t,  "Y", char_field, 100 );
      }

      void add_record( table& t )
      {
            record& r = t.new_record();
            r[ "X" ] = x;
            r[ "Y" ] = y;
            r.save();
      }

};

void f()
{
    A a,b;
    in_memory_builder b;

    table & t = b.create_table();
    A::define_table( t );
    a.add_record( t );
    b.add_record( t );

    to_xml( t, "out.xml" );
    to_gui( t );
}
<\code>

Different relational db platforms implement its own builder.
Builder knows about which features are supported (field types, nested tables).
If some feature is not supported it can implement it using some workaround
or report error ( unsupported feature ).
   One of useful platforms can be in-memory container with all
features supported. It can be easily stored/loaded to from XML.
Some kind of in-memory relational database.  It can also transparently
work with different GUI controls. Besides all it can be used to cache
relational data stored on remote rdb server.

> And will that set of tables be
> easy to work with?

IMHO Yes.
At least in memory relational tables isn't my idea.
.Net and Borland builder have it and they doesn't look
very complicated.

---------------------------------
Classes :
    rdb_data
        record,
        table,
        field,
            simple_field,
            nested_table_field,
    serializer,
        xml_serializer

... does not look very complicated.

I agree that not everything is smooth. At least i can see problems with
heterogeneous collections,
But i believe they can be solved somehow.

regards,
bohdan