[odb-users] Help, how to generate the hxx files automately by odb
Hugo.Mildenberger at web.de
Hugo.Mildenberger at web.de
Fri Mar 1 09:18:25 EST 2013
Hi Boris,
On Fri, 1 Mar 2013 14:32:43 +0200
Boris Kolpackov <boris at codesynthesis.com> wrote:
> I don't see anything wrong with this as an example of mapping a C++
> class to a custom (existing) schema.
>
> At the same time, if we are talking about automatically generating
> C++ classes from the database schema, then this would be a good example
> why some (including myself) think that we could be opening a big can of
> worms ;-).
Leaving aside rotten cans and also neglecting the real costs of data round trips (e.g. http://blog.endpoint.com/2012/10/the-real-cost-of-data-roundtrip.html) plus the potential costs of inconsistencies and data leaks (which both become more likely with more data on the wire and more SQL statements created on the fly), the crucial question is where the complexity should reside.
I do prefer clearly defined interfaces and thus self-contained, testable units on all implementation levels, but I can understand that you have to fear high support costs assuming that many of your clients may choose to use pre-existent databases with ODB, simply because you also provided a class mapper.
> Specifically, I don't see ODB being able to figure out what's going on
> in this example: i.e., that there is an "updatable" view of two tables
> and that it should map this view to an object instead of mapping the
> other two tables to two separate objects. ODB can't yet read someone's
> mind ;-).
It would be sufficient if a table-to-C++ class mapper was able to read his own command line options, say --views-only or --tables='odb_.*'. However, it might be difficult to read the mind of a database view when it comes to primary keys and data types. I haven't looked into this detail yet, but because the definition of a view lists and associates any table and column it draws the data from, it should also be possible to query the system tables for views as it is possible for 'real' tables. That way you could even detect the case when your traditional, read-only view model is appropriate and sufficient.
Hugo
More information about the odb-users
mailing list