[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