[odb-users] design questions: c++ / python / sqlite
finjulhich at gmail.com
Thu May 22 17:31:09 EDT 2014
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
> the primary key is name, and the other things are other columns, and yet
> > 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.
More information about the odb-users