[odb-users] Unique index in abstract class

[Патрушев Данил Андреевич]

>Yes, this is a good workaround (and that's essentially what ODB would
>do once we fix the bug). What is not clear is the "no longer works"
>part: the only way I see this happenning is if your table names were
>clashing.

Hi, again. I finally traced the issue down to a faulty pragma, which was intended to specify a unique index on that shared field,  in one the containers. It said:  "#pragma db member(m_field) unique not_null".  After changing this to "#pragma db index unique member(m_field)" this got back to normal again.





С уважением,
Инженер-программист
ООО «Прософт-Системы»
Патрушев Данил Андреевич
________________________________
От: Boris Kolpackov <boris at codesynthesis.com>
Отправлено: 1 октября 2020 г. 20:40:35
Кому: Патрушев Данил Андреевич
Копия: odb-users at codesynthesis.com
Тема: Re: [odb-users] Unique index in abstract class

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

> 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.

No problem, precision is always appreciated.


> 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.

Yes, this is a bug in ODB.


> 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.

Yes, those "B_" and "C_" prefixes in the index names are the table names
of B and C.


> I don't know if this is legal but this approach used to work for us
> for some time, but it no longer does.

Yes, this is a good workaround (and that's essentially what ODB would
do once we fix the bug). What is not clear is the "no longer works"
part: the only way I see this happenning is if your table names were
clashing.


> Considering what I've tried to get across, do you still recommend
> the mechanisms you mentioned in your reply?

That depends on the reason why your workaround no longer works.