[odb-users] [Question] Reverse code generation (.h from .sql)

[Boris Kolpackov]

Hi Alexey,

[CC'ed odb-users; please keep the mailing list CC'ed to your replies]

Alexey Afanasyev <aphongka at gmail.com> writes:

> 1) we are going to add some new functionality to our application based
> on an existing database. In this case we just invent new entities and
> map them to the new db. Here, automatic conversion from  SQL to C++
> might spare our time;

Agreed.


> 2) we are switching to a database from another supplier, or our app
> allows our customers to chose which database to use from a number of
> databases of the same kind (covering the same domain but having
> different schemata). In this case, we can try directly map each of the
> databases to our C++ classes using pragmas. This mapping might be not
> trivial and hardly automated. But there is another way to settle the
> issue - automatically map each of the DBs to C++ and then at C++ level
> create wrappers or adapters to unify access to all of them. So, SQL 2
> C++ conversion might help here as well.

Also agreed.


> But even if the DB was under our control and we were at the production
> stage we would have difficulty to change our C++ objects without
> appropriate changes in the DB. In my former project we used the
> following method which was robust enough:
> 
> - start with DB schema, create appropriate DB change and migration scripts;
> - auto-generate entities from the changed DB schema;
> - use the changed entities in the code.

Yes, this is a common approach. We plan to support (more or less) automatic
schema migration in the future so if you choose to use C++ classes as the
primary specification of your object model (instead of the database schema),
then the ODB compiler would generate the migration scripts/code for you.


> Well, my scenario is something like I have described above. There is
> an existing DB which I use in my application. But there is a number of
> the DBs of the same kind on the market. So I have to keep in mind that
> one day I might switch to a different schema.
> 
> So, in my scenario, I need to generate C++ classes (headers) from the
> existing DB schema. I do not need to generate schema from C++ classes.
> I do not need to regenerate C++ often, while I might need to do so in
> case my DB provider changed the schema or I switched to different
> database.
> 
> But I am also thinking of possibility of round-trip engineering.
> 
> I see the difficulty with constant regeneration of the C++. I guess
> simple inheritance won't work, will it?

Inheritance will break in two places:

(1) If there is inheritance between generated entities (in this case
    the derived class will inherit from the generated version instead
    of the hand-written one). Maybe we could work around this with
    virtual inheritance.

(2) If there is a relationship between objects (object pointers).


I also have another question regarding your use-case. Does your schema
define anything that you would want to map to composite value types,
containers, or object relationships? The reason for this question is
that it won't be possible to automatically decide that something
should be mapped to a composite value type (instead of just a set
of data members directly in the object), a container (instead of
just another object), or one-to-one relationship (instead of just
the generic many-to-many). So we would probably have to have some
kind of a mapping file which tells the ODB compiler how to map SQL
tables to C++ classes.

Also, would it be possible for you to send me your schema (off-list)
so that I can take a look?

Boris