From d.patrushev at prosoftsystems.ru Thu Oct 1 01:53:23 2020 From: d.patrushev at prosoftsystems.ru (=?koi8-r?B?8MHU0tXbxdcg5MHOycwg4c7E0sXF18ne?=) Date: Thu Oct 1 02:11:58 2020 Subject: [odb-users] Unique index in abstract class Message-ID: <19cff058b1304bcaae96a44d0f2d36a8@prosoftsystems.ru> Hello. 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). By removing some of the dependencies I was able to make it go away, but that comes at cost of some useful functionality that ODB provides (like object relationships). Is there a recommended approach to handling an issue like this or does it look like a bug? From boris at codesynthesis.com Thu Oct 1 06:18:25 2020 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Oct 1 06:36:51 2020 Subject: [odb-users] Unique index in abstract class In-Reply-To: <19cff058b1304bcaae96a44d0f2d36a8@prosoftsystems.ru> References: <19cff058b1304bcaae96a44d0f2d36a8@prosoftsystems.ru> Message-ID: ???????? ????? ????????? 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. From d.patrushev at prosoftsystems.ru Thu Oct 1 08:58:08 2020 From: d.patrushev at prosoftsystems.ru (=?koi8-r?B?8MHU0tXbxdcg5MHOycwg4c7E0sXF18ne?=) Date: Thu Oct 1 09:16:33 2020 Subject: [odb-users] Unique index in abstract class In-Reply-To: References: <19cff058b1304bcaae96a44d0f2d36a8@prosoftsystems.ru>, Message-ID: 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 ??????????: 1 ??????? 2020 ?. 15:18:25 ????: ???????? ????? ????????? ?????: odb-users@codesynthesis.com ????: Re: [odb-users] Unique index in abstract class ???????? ????? ????????? 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. From boris at codesynthesis.com Thu Oct 1 11:40:35 2020 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Oct 1 11:59:02 2020 Subject: [odb-users] Unique index in abstract class In-Reply-To: References: <19cff058b1304bcaae96a44d0f2d36a8@prosoftsystems.ru> Message-ID: ???????? ????? ????????? 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. From d.patrushev at prosoftsystems.ru Mon Oct 5 06:13:30 2020 From: d.patrushev at prosoftsystems.ru (=?windows-1251?B?z+Dy8PP45eIgxODt6OsgwO3k8OXl4uj3?=) Date: Mon Oct 5 06:32:19 2020 Subject: [odb-users] Unique index in abstract class In-Reply-To: References: <19cff058b1304bcaae96a44d0f2d36a8@prosoftsystems.ru> , Message-ID: >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 ??????????: 1 ??????? 2020 ?. 20:40:35 ????: ???????? ????? ????????? ?????: odb-users@codesynthesis.com ????: Re: [odb-users] Unique index in abstract class ???????? ????? ????????? 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. From microcaicai at gmail.com Wed Oct 21 08:17:47 2020 From: microcaicai at gmail.com (microcaicai@gmail.com) Date: Fri Oct 23 07:11:34 2020 Subject: [odb-users] [PATCH] libodb-pgsql: correct reference to rnull. Message-ID: <20201021121747.1765426-1-microcaicai@gmail.com> From: microcai rnull[1] has only 1 element, thus rnull[1] is illegal. --- odb/pgsql/database.cxx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/odb/pgsql/database.cxx b/odb/pgsql/database.cxx index 5c60957..51752d7 100644 --- a/odb/pgsql/database.cxx +++ b/odb/pgsql/database.cxx @@ -319,7 +319,7 @@ namespace odb native_binding nparam (values, lengths, formats, 1); bool rnull[1]; - bind rbind[1] = {{bind::boolean_, &exists, 0, 0, &rnull[1], 0}}; + bind rbind[1] = {{bind::boolean_, &exists, 0, 0, &rnull[0], 0}}; binding result (rbind, 1); result.version++; -- 2.28.0 From boris at codesynthesis.com Fri Oct 23 07:09:40 2020 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Oct 23 07:29:17 2020 Subject: [odb-users] [PATCH] libodb-pgsql: correct reference to rnull. In-Reply-To: <20201021121747.1765426-1-microcaicai@gmail.com> References: <20201021121747.1765426-1-microcaicai@gmail.com> Message-ID: microcaicai@gmail.com writes: > rnull[1] has only 1 element, thus rnull[1] is illegal. Applied, thank you.