5

If there is only one instance to be created, I agree you should use a singleton for your case instead of a table directly, as this is what singletons are used for. For API, you can check the eosio/singleton.hpp file, and here's a quick example using a singleton: #include<eosio/eosio.hpp> #include<eosio/singleton.hpp> class singleton_example : ...


5

When making structural changes to tables there are 2 basic approaches: add versioning in the data from day 1 and then support old versions of the data well enough to do "just in time" upgrades. deploy a migration contract in-between version N and N+1 which can read the data and convert it, OR ingests transactions with data converted in an out-of-chain ...


4

I guess your problem might be that you are saving the primary key as uint32_t but it has to be a uint64_t. Because it might be that if you try to save the id (0x00000000) it will cut the last 32 bits (0x0000) and result in a 0x0000. If you try to save a new one then you would expect 0x00000001 which will also be cut to 0x0000. The available_primary_key() ...


1

Yes, as you're saying, it should simply be a single table with a single row that contains your data as a struct with the 3 fields. You would need to define your struct and table as something like this: //@abi table state i64 struct state { string field1; string field2; uint64_t field3; // Set the primary key to a constant value to store ...


Only top voted, non community-wiki answers of a minimum length are eligible