Open jcalfee opened 6 years ago
This would be greatly beneficial. I very rarely use the scope feature because it prevents me from getting all records. Additional filtering capabilities would also be highly beneficial.
I guess there could be a scalability or performance concerns. No guarantee that you can do everything within the CPU limit for the block so that may need in-contract paging. Still probably better to have it than to find out after a contract deployed that this is not possible.
Internally, table_id_multi_index
has the by_code_scope_table
index. We could expose lower_bound
, find
, and iteration on this index to contracts in a future hard fork.
by_code_table_scope
would probably be more convenient, but since it doesn't already exist it would increase row ram costs.
scope can be useful when you need to store something between 2 different accounts. For example, delegatebw uses scope as delegator and key as the account receiving the resources. But I agree there's no way to iterate over a scope.
Please follow https://github.com/EOSIO/eos/pull/5486
Any progress on this?
In addition to allowing iterating over scope, the get scope cleos command and API should be changed to only iterate over the scopes of the specified table (when given).
For example, if there is a token contract with several tokens (and 100k account owners). I want to get just all the tokens types from the contract (that is, I want all the scopes of the stats table).
However, the way it works, because it iterates over all scopes (and because of the accounts table, there will be thousands), I will have to keep running this command several times with new lower bounds to get all my token types.
@znebby The iteration order is controlled by the available indexes. Adding indexes to nodeos increases ram consumption. This particular application is better suited for external databases.
In some cases developers are choosing not to use the table scope because it lacks an iterator or a lookup function. Seems like that is not a security concern. If not, if that were added I think we would get contracts that are a little easier to query (get_table_rows contract >>scope<<) and make use of that built-in index.
Kevin
James :+1: