[odb-users] Unique index in abstract class

Патрушев Данил Андреевич d.patrushev at prosoftsystems.ru
Thu Oct 1 08:58:08 EDT 2020

Hi, first, I appreciate your attention. Second, I don't see how there can be a table name conflict. I am going to present an example, please, excuse me for stating obvious things, just want to be absolutely clear. Say "A" is an abstract class, "B" inherits "A" and is concrete, "C" inherits "A" and is concrete. ODB generates two tables named "B" and "C", correct?  Now,  we would like to apply a unique index to a field in "A", which is shared. The first thing to try is to add

#pragma db index unique member(m_field) in "A". That gives us index "A_field_i" in the definition of "B" and index "A_field_i" in the definition of "C" -  same name. The table names are still different, why shouldn't they? I suppose it is the scope of the index definition, namely, class "A" that drives the choice of the index name.  We worked around the issue by writing #pragma db index unique member(m_field) in the body of "B" (we reference m_field which is defined in "A") and the same pragma in the body of "C". That gave us "B_field_i" in "B" definition and "C_field_i" in "C" definition. I don't know if this is legal but this approach used to work for us for some time, but it no longer does. Considering what I've tried to get across, do you still recommend the mechanisms you mentioned in your reply?

От: Boris Kolpackov <boris at codesynthesis.com>
Отправлено: 1 октября 2020 г. 15:18:25
Кому: Патрушев Данил Андреевич
Копия: odb-users at codesynthesis.com
Тема: Re: [odb-users] Unique index in abstract class

Патрушев Данил Андреевич <d.patrushev at prosoftsystems.ru> writes:

> I have an abstract database class inherited by a bunch of concrete database
> classes. The shared abstract class contains a data member which, according
> to the plan, must have a unique index. If we provide a definition of the
> index inside the abstract class ODB generates unique indices sharing the
> same name (say, AbstractClassName_columnName_i) which is not good. We tried
> putting the index specification into the concrete classes (by referring to
> the base class member in the pragma) and this approach actually worked until
> recently.  Latest modifications in our code base introduced new dependencies
> between database classes which made the dreaded same name index definition
> appear again (alongside the good definition).

I am surprised you haven't also gotten table name conflicts in this case
(or maybe I am not seeing the complete picture from your description).

There are two mechanisms in ODB for dealing with this kind of issues:
database schemas (Section 14.1.8) and table prefixes (Section 14.5.2).
I would suggest that you try the simpler table prefix approach to see
if you can make it work.

Another idea (that would work best if the conflicts do not happen in
the same header files), is to use the --index-regex option to mangle
index names to make them unique.

More information about the odb-users mailing list