10

EOSIO keeps the state in RAM. All the data for the contracts and transactions are held in RAM. All block producers (BP) process the transactions and keep an updated state of the database in RAM. This is why the RAM is one of the most valuable resources in the EOSIO blockchain and has it's own mechanism for reserving and pricing it. You should seek ways to ...


10

So, for this scenario we can create another index that concatenates both indexes and look for it. As an example, let's see a scenario where we can invite accounts to a group and each invitation has an id. // table declaration for invites // @abi table invitation i64 struct invitation { uint64_t id; uint64_t group; account_name user; ...


9

Action names, table names, index names, account names, and everything else you use N(foo), "foo"_n, or eosio::name("foo") for, have these rules. A contract belongs to an account. 12 characters max May contain: a-z, 1-5, or . May not end with . Names are encoded in base-32: . = 0 1-5 = 1 - 5 a-z = 6 - 31 The 5 MSBs of the uint64 contain the first ...


9

Some further explanation of how the value to pass via cleos was derived. As already mentioned in the original post, this all revolves around endianness. For some reason the checksum256 value is returned in a different endian to what the index key type bounds for sha256 expects. If you have the below hash (checksum256) returned by a row in the table: ...


8

After I didn't find any other solution, I ended up with a sequential workaround which will delete all records by time. Disclaimer: Be sure to block all other actions that would rely on the index, because data will invalidate during deletion and new data maybe deleted as well. And you may add some authorization because not everybody should be able to delete ...


7

Have a look to available_primary_key in the EOS documentation, multi indexes do support auto increment keys.


5

If I understood everything correctly: A transaction stores multiple actions. Transactions are stored in blocks. Every block producer has its turn (approx. 0.5 sec for this DPOS) to create a block and execute the corresponding transactions including their actions deterministically. If there would be concurrent write access of multiple block producers to the ...


5

If your table doesn't have any elements, then it will throw this error. Whenever you use the find command, always check afterwards that an element was found: auto element = candidates.find( id ); if(element != candidates.end()) { return element_name; }


5

According to the official documentation you can find here: They are multi index tables because they support using multiple indexes on the data, the primary index type must be uint64_t and must be unique, but the other, secondary, indexes can have duplicates. You can have up to 16 additional indexes and the field types can be uint64_t, uint128_t, uint256_t, ...


4

For "multi-index" searches I use one index to perform the search on my primary, then simply loop through the iterator until I either find the item I'm looking for with the matching secondary key. Obviously, you should search first with the key that will return the fewest matches so that the loop can abort as soon as the iterator's primary key no longer ...


4

UPDATE: It seems Block.one does not plan to implement the functionalities necessary for scopes to actually make any difference in performance, which renders scopes useful only for separating your data for easier access. Reference: https://github.com/EOSIO/eos/issues/4357 Yes, basically scope exists for 2 reasons: Allows you to separate records that do not ...


4

Agree no size is maintained by EOS implementation , the iterators are not random access , so if size state not maintained (which would be best performance compared to calculating size on the fly when needed) then more compact expression to get the size ( if you really need it as I don't see the use case yet) is to use std::count auto size = std::count(...


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() ...


3

From your code I assume you want to delete all entries on the table that have less than 100 exp. The biggest problem I see here is not limiting how many items you delete from the table. As in this code you can possibly be telling the contract to delete 1000's of items in a single action. Which causes a "transaction took too long" error. void ...


3

the problem is that the primary key index cannot be 128 bits long. it must be 64 bits. but other indexes can be 128 bits so my solution was to implement an auto-generated monotonic primary key and then define the index I wanted as a secondary index struct [[eosio::table]] _prices { uint64_t id; symbol base; symbol quote; ... ...


2

EOS.IO stores indexed state in a custom-written database engine called Chainbase. This database is optimised for high performance when the entire database fits into memory, and it's expected that block producers will have enough physical memory to accomodate this (as they risk missing their block production windows otherwise). However, it will degrade ...


2

Multi-index is the only option. An arbitrary account can modify the table through an action sent to the contract for the particular account.


2

For example, if I launched that tic-tac-toe demo to the mainnet, where is its Multi-Index table data stored? Does RAM always caches the current state of the table? The Multi-Index struct content is exactly what is saved on ram and for all the smart contracts. At a moment all BPs will have in memory, every single table for every single smart contract posted ...


2

i have solved this question. I execute the command ”./cleos -u "http://dev.cryptolions.io:38888" get table xun xun cates --key-type i64 --index 2“ then i get the socket data packets use wireshark. i found this : cleos comment: --key-type --index rpc comment: key_type index_position


2

you can get the ram consume before version 1.2.3 like this: void apply_context::update_db_usage( const account_name& payer, int64_t delta ) { if( delta > 0 ) { if( !(privileged || payer == account_name(receiver)) ) { require_authorization( payer ); } } dlog("the ram used is${delta}",("delta",delta)); trx_context....


2

As per this description i can say that at the time of deployment called A you have not added that table abi that's why you are not able to call getTableRows() but actually the table actions have executed and made entries on table and occupied RAM also.Now, what happens when you redeployed the same contract with same account and made some changes but that RAM ...


2

Figured it out, trick was to use a combination of checksum256 and key256. Used the dice contract as an example: struct offer { uint64_t id; account_name owner; asset bet; checksum256 commitment; uint64_t gameid = 0; uint64_t primary_key()const { return id; } uint64_t by_bet()...


2

The EOS multi-index table is based on Boost multi-index containers. From this question and this question it doesn't seem possible to store classes directly as fields, but it seems possible to manage class inheritance with proper indexing and handlers.


2

You can call name.value to get a uin64_t representation of the name. In your find call, you want to do auto iterator = host_games.find(host.value); to match the uint64_t type that your secondary index is returning.


2

The N macro was replaced with the _n operator. It is one of the breaking changes introduced recently. Here is the complete list, https://github.com/EOSIO/eosio.cdt/blob/master/README.md Removal of the N macro. The ""_n operator or the name constructor should be used as a type safe replacement. Example: N(foo) -> "foo"_n, or N(foo) -> name("foo").


2

This is the functionality that the multi index was based around. To get the name, simple add .value to your key on return: uint64_t primary_key() const { return key.value;} // key.VALUE In the tutorial, they actually use a uint64_t for the secondary index. That's all eosio::name is under the hood, a uint64_t. Granted they use it to represent an age by a ...


2

Ok I found the problem, I'll put it here so the next guy won't do the same. I was zeroing the act value inside the loop, so somehow the iterator kept hitting the same row with a value < 0. The solution was to change to a while loop and instead of incrementing i, get a new lower bound (it will move the iterator forward anyway). Not sure if this is very ...


2

You can return auto. Your code example would then look like this: // attention, undefined behaviour auto test() { myTable t{_self, _self.value}; return t.find(...); } In your code example, however, the variable t is stack allocated and goes out of scope at the end of the function. That results in undefined behaviour since you are now returning an ...


2

You can't use a string as key type. A secondary index supports several key types, listed below. uint64_t - Primitive 64-bit unsigned integer key uint128_t - Primitive 128-bit unsigned integer key, or a 128-bit fixed-size lexicographical key checksum256 - 256-bit fixed-size lexicographical key double - Double precision ...


2

EOSIO.CDT doesn't support std::array in function argument or field of multi_index struct. You can try my customized version of cdt, eoscc which supports std::array. If you want to use official EOSIO.CDT, you had better use std::vector, but limit the number of items by yourself.


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