[odb-users] composite ID containing an auto-incrementable field

Sten Kultakangas ratkaisut at gmail.com
Fri Jul 24 01:36:00 EDT 2020


Hello

I know that composite IDs have some restrictions but I made a conclusion
that this issue can be fixed with relatively low effort.

The problem is that in the following case odb does not generate a valid
code needed to persist the object:

#pragma db value
struct ObjectId {
#pragma db auto
long long id = 0;
long long tenant_id = 0;
};

#pragma db object schema("GenericSwitch.dbo")
struct Extension {
#pragma db id column("")
ObjectId key;

#pragma db type("varchar(16)")
std::string extension;
};

Here's the generated INSERT statement:

const char access::object_traits_impl< ::GenericSwitch::Extension, id_mssql
>::persist_statement[] =
  "INSERT INTO [GenericSwitch].[dbo].[Extension] "
  "([id], "
  "[tenant_id], "
  "[extension]) "
  "VALUES "
  "(?, ?, ?)";

Instead it must not contain the id field and must contain the OUTPUT
INSERTED keyword:


const char access::object_traits_impl< ::GenericSwitch::Extension, id_mssql
>::persist_statement[] =
  "INSERT INTO [GenericSwitch].[dbo].[Extension] "
  "([tenant_id], "
  "[extension]) "
  "OUTPUT INSERTED.[id] "
  "VALUES "
  "(?, ?)";

This also requires some modifications to the code which generates
access::object_traits_impl< ::GenericSwitch::Extension, id_mssql
>::persist()

Boris, I am going to make the necessary modifications to
odb/relational/source.cxx and odb/relational/mssql/source.cxx but i wonder
if you have some work-in-progress branch having the relevant modifications
that I can easily backport to the stable 2.5.0 branch ?

If you haven't yet worked on this issue, then do you have instructions for
contributors on how to make a patch that can be incorporated into the
official version control branch ?

P.S. Actually tenant_id does not belong to the primary key, but i see no
other way to force odb to generate UPDATE statement having condition WHERE
tenant_id=X and id=X which is necessary for data integrity as our API does
not currently perform sanity-checks on the user-supplied ID but instead it
determines the tenant the API user belongs to.


Best regards,
Sten Kultakangas


More information about the odb-users mailing list