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

MM finjulhich at gmail.com
Mon Jun 2 08:01:33 EDT 2014


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

> Hi,
>
> MM <finjulhich at gmail.com> writes:
>
> > 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.
>
>
> > 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.
>
> Boris
>
I have managed to generate the sql for this. As a reminder here:

class ABClass {
public:
 virtual ~ABClass();
 // other virtuals
 // 2 pairs of getters/setter for name and hols
protected:
  ABClass()
private:
  const std::string* name_;
  std::vector<boost::gregorian::date> hols_;
};


class D1 .... D10 : public ABClass { ... };

All Ds are singletons. Their name_ points to a static list of strings, so
D1's name_ points to "D1"

So the names themselves and the single instances  D1...D10 currently are
statics in the C++ code, and I intend to have the hols data in the database.

Now, I'll get rid of the statics and have everything stored in the db.
There are indeed the ABClass table + all the D tables.

I assume a query like

result r (db->query<ABClass >());

would just work and load up all the Ds instances in 1 go?


More information about the odb-users mailing list