Wt

Hey Michael,

There is a chance, but it currently hasn't been done and the library needs quite some changes to extend the currently simple concept from

table <-> class

to

multiple tables <-> class of type depending on table data

I believe we would also need a dbo::dynamic_ptr_cast<> to convert from ptr to ptr (but that does not sound too hard)

Finally, as I think of how to implement it, the biggest difficulty may be to mix run time polymorphism with the template 'persist()' method, although I cannot immediately say what might make this impossible.

I wish it was easier. I think you have only one workable option with the current state of affairs: not bother about the virtual hierachy of Layer, FeatureLayer and RasterLayer but treat them as 3 different classes with a (1-1) relation. But because 1-1 relations are not supported directly, you will need to implement it as a 1-N relation (an artifact which you can hide in your class interface though).

Another option could be to have your hierarchy of Layer, FeatureLayer and RasterLayer and implement these in terms of 3 implementation classes which are themselves mapped on the tables --- this would work from the point of view from the rest of your application except that you would not be able to treat these classes as dbo classes which would not be consistent with possibly other dbo classes.

Regards,

koen

Hi Koen,

Many thanks for your prompt reply. I solved my issue by using the "table per concrete class" approach for the database schema. I put the attributes from table "layer" in tables "featurelayer" and "rasterlayer" and droped the "layer" table. My C classes still reflect inheritance between Layer, RasterLayer and FeatureLayer and everything works fine.

If I had a wish list for the dbo library it would look as follows:

• Support for composite primary keys
• Support for primary keys of arbitrary data type and name

Many thanks again,

Michael

Hey Michael,

Glad to hear you solved it!

Support for custom types for primary keys (be it composite or another type) is a tough change. We made the choice for surrogate keys in order to not complicate the initial implementation to see whether the other ideas worked fine, but it will not be easy to generalize the long long to a dbo_traits::key_type.

A custom name instead of 'id' would be an easy change however.

We are currently giving priority to improve the integration in Wt, and to provide support for join-fetching of collections.

Regards,

koen

Hi Koen,

With "composite" I meant a primary key consisting of more than one column whereas the column types would still be basic data types such as "int", "varchar(x)", etc.

Many thanks,

Michael

Just for the record (I am cleaning out pending emails): this has been implemented in Wt 3.1.4

Regards,

koen