[odb-users] design questions: c++ / python / sqlite

[MM]

On 22 May 2014 19:47, Boris Kolpackov <boris at codesynthesis.com> wrote:

> > I just meant that a given class is defined in C++. I would expose that
> > class in python with boost.python perhaps, and then use those classes in
> > python to access the sqlite db through python.sqlite
>
> This doesn't make much sense to me. You have C++ classes that you
> can persist in the database with ODB. You expose them to python via
> Boost.Python. You then use these classes and SQLite support in Python
> to access their state in database? Why? That is already handled by ODB
> on the C++ side.
>
I'm sorry, I may have made a mistake in what I said before.
The python code would fill up the existing tables that have been generated
from ODB, with data.  I write the sqlite also from python. To do that, I
would need to know the columns of the tables. Having the  C++ class that
odb used to generate the table, exposed as a python class, should help for
my python code to write to the tables?
The C++ part then reads and writes the data too.

If it can't be done, then I could duplicate the members of each table in
the python code as well.



>  > Is there a way to make this map to a single table that holds 10 rows
> where
>
> the primary key is name, and the other things are other columns, and yet
> on
> > loading back from the table, that the correct concrete instances are
> > created?
>
> What you are looking for is the table-per-hierarchy mapping for
> inheritance. This is currently not supported by ODB. See Section
> 8.2, "Polymorphism Inheritance" in the ODB manual for details.
>
>
> > If not, how to change my simple class hierarchy?
>
> You don't really have to change anything. Just use the table-per-
> difference mapping supported by ODB. You will end up with some
> extra tables that (seemingly) are not necessary, but other than
> that, everything will work as expected. In fact, the root table
> will look as if you were using the table-per-hierarchy mapping
> so if your Python code only needs to read the data, then you
> can treat it in Python as such.
>
All right. I'll see what pragmas for the ABC if any, and what pragmas for
the derived classes.


> Boris
>
Thanks