Document that update intrinsics of C DB API cannot change primary key

[arhag]

The current (as of v1.0.5) update intrinsics of the C DB API do not allow changing the primary key of a table row. The serialized data that is stored in the table row of a primary table may include a primary key and that primary key value could be changed by the contract calling the db_update_i64 intrinsic. But that does not change the actual primary key recognized by the native side.

This behavior should be well documented for contract developers that use the C DB API. Those using the C++ multi_index shouldn't have to worry about this (although it should still be documented) because the modify method will check that the primary key was not changed by the updater lambda and cause an assertion failure otherwise.

[dixia]

is this ticket still valid?

[lparisc]

Yes according to @arhag. The description or remarks section of the db_update_i64() intrinsic just needs to specify that the primary key won't be updated (which is obvious but should still be said).

[iamveritas]

the dev portal is currently picking up the annotation from the eos repo file
eos/libraries/chain/include/eosio/chain/webassembly/interface.hpp

and it is placing it here
https://developers.eos.io/manuals/eos/v2.1/classeosio_1_1chain_1_1webassembly_1_1interface/#function-db_update_i64

therefore is it ok to move this issue to eos repo?
@larryk85 @arhag @nksanthosh

[larryk85]

the dev portal is currently picking up the annotation from the eos repo file
eos/libraries/chain/include/eosio/chain/webassembly/interface.hpp

and it is placing it here
https://developers.eos.io/manuals/eos/v2.1/classeosio_1_1chain_1_1webassembly_1_1interface/#function-db_update_i64

therefore it is ok to move this issue to eos repo?
@larryk85 @arhag @nksanthosh

The host function implementations aren't the same as the C API in CDT with respect to the interface. If that is the path we are looking to take. I.e. moving the documentation from CDT to EOS, then we need some transforms for the types. If not it will be incredibly non-obvious to contract devs and toolchain devs as to what a span is or some of the other implementation details on EOS side of things types. But, if that is the case then yes it should move. I would say, that I think it will be a bit worse than just having the same documentation (worded a bit better for contract devs and with the correct types) on the CDT side. The documentation in EOS for those should allow someone to build a clone of the software or external tooling that implements those functions with that interface and have something like eos-vm bind to those and work.