Lack of Default Primary Index Information in Antelope ABIs

[dafuga]

Hello,

I am part of the team developing Wharf (https://github.com/wharfkit), we've come across an issue where Antelope's ABIs does not provide a mechanism to determine the default or primary index of a table. It seems that the ABI only provides information on the primary index if there's a secondary index present.

For example, in the eosio namebids table, the primary index is not included in the key_names field:

{
  "name": "namebids",
  "index_type": "i64",
  "key_names": [],
  "key_types": [],
  "type": "name_bid"
}

However, in the case of a table where secondary indexes exist, the key_names field does seem to include the primary index. For example, the decentiumorg trending table has the primary index data included in that array:

{
  "name": "trending",
  "index_type": "i64",
  "key_names": [
    "id",
    "score",
    "cscore",
    "permlink"
  ],
  "key_types": [
    "uint64",
    "uint64",
    "uint128",
    "uint128"
  ],
  "type": "trending_row"
}

As part of our ongoing development of the Wharf Contract kit, we are working on creating contract-specific helper functions to facilitate developers' use of the get_table_rows API. Our goal is to provide strongly typed functions to Wharf users. This will only be possible if we can determine the primary index of any given table from the contract ABI.

Given these requirements, could you consider always including the primary index information in the key_names and key_types arrays, regardless of whether a secondary index exists or not? This change would ensure a consistent understanding of the default indices across all tables and greatly assist in the creation of developer-friendly functions in the Wharf Contract kit.

Thanks,
Daniel

[dimas1185]

@dafuga currently cdt doesn't fill out key_names and key_types. We can consider adding this feature.
Please let me know what generated those abi's. when you call cleos get abi it returns you an abi that was used while deploying the contract. If someone edited it manually before uploading it, you can edit it by yourself and update using cleos set abi command

[dimas1185]

Here is some scrutiny results:

[larryk85](https://github.com/larryk85) commented [on Oct 10, 2018](https://github.com/EOSIO/eosio.cdt/issues/106#issuecomment-428804975)
The type is invalid issue with vectors has been resolved in v1.3.0. As for key_names and key_types, they are ignored, as they are a deprecated part of the abi, these fields are a hold over from a different system for secondary tables and no longer make any sense.

And here is original commit (due to different project structore 5 years ago this file is in a different repo):
EOSIO/clang#8
corresponding eosio.cdt PR - EOSIO/eosio.cdt#67

So key_names and key_types are deprecated fields and your contract was likely generated using 5 years old cdt. Are you looking for adding them back?

[ericpassmore]

@dafuga from our research this has not been supported for several years, and was deprecated. For contracts compiled with CDT version 3.x or 4.x are you able to see a primary index when there is a secondary index? From our review of the code the index fields are never returned.

We are removing the bug label, and treating this as a feature request. We will discussion the right priority for this work.

[aaroncox]

Apologies for the delayed response!

The contract in question @dafuga was mentioning was probably 4-5 years old at this point, so this makes sense.

If they've been gone that long and deprecated, then we could consider this a feature request (of somewhat high priority?).

We need some way to identify what the table indices are, preferably by interpreting the ABI. We are using that information to map our new table querying language to the appropriate indices when calling get_table_rows in @wharfkit.

To illustrate the mapping we're doing, the SDKs converting the index_position and key_type fields in get_table_rows requests like this:

{
  code: 'eosio',
  table: 'namebids',
  scope: 'eosio',
  index_position: 2,
  key_type: 'i64',
}

Into a more simply syntax where you can simply specify the field name.

contract.table('namebids').query({
    index: 'high_bid',
})

It maps that high_bid field name to index_position: 2 and key_type: 'i64' through the ABI.