Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

getting table row with secondary key(--key-type sha256) returned wrong result #6648

Open
elbowlicker opened this issue Jan 22, 2019 · 14 comments

Comments

Projects
None yet
9 participants
@elbowlicker
Copy link

commented Jan 22, 2019

I tried to get the row of the table using secondary key but inexpected row have been returned. I have tested with eosio v1.6.0-rc1

The following code is my rows of the table. The "user_hash" is the secondary key and it is "checksum256".

{
  "rows": [
    {
      "user_id": 0,
      "user_hash": "940ade173dce37480f6ab974a2e235f69e5128ba3804574ab10877bc5f503ee7"
    },
    {
      "user_id": 1,
      "user_hash": "fdfa94e8850f7a8b2952ac6091215a201687ea7dd4791359ac03954a12acfa0c"
    },
    {
      "user_id": 2,
      "user_hash": "4951ed9dcdc34a39fcf1dae154475c64e385962ff6856c2069072a42fffb9081"
    }
  ],
  "more": false
}

I have tried to get the row with following command.
cleos get table codename scopename tablename --index 2 --key-type sha256 -L 940ade173dce37480f6ab974a2e235f69e5128ba3804574ab10877bc5f503ee7

@elbowlicker elbowlicker changed the title getting table row with secondary key(--key-type sha256) returned wrong element getting table row with secondary key(--key-type sha256) returned wrong result Jan 22, 2019

@taokayan

This comment has been minimized.

Copy link
Contributor

commented Jan 22, 2019

Please add -U 940ade173dce37480f6ab974a2e235f69e5128ba3804574ab10877bc5f503ee7 as well. Basically you need to specify the upper bound if you only want row(s) with exact key to be returned.

@taokayan taokayan added the Support label Jan 22, 2019

@elbowlicker

This comment has been minimized.

Copy link
Author

commented Jan 22, 2019

Please add -U 940ade173dce37480f6ab974a2e235f69e5128ba3804574ab10877bc5f503ee7 as well. Basically you need to specify the upper bound if you only want row(s) with exact key to be returned.

Thank you for answer. But unfortunately adding "- U 940ade173dce37480f6ab974a2e235f69e5128ba3804574ab10877bc5f503ee7" did not solve the prolem. It didn't get any results. Also, I got the same result too when I added "-U 940ade173dce37480f6ab974a2e235f69e5128ba3804574ab10877bc5f503ee8"

@taokayan

This comment has been minimized.

Copy link
Contributor

commented Jan 22, 2019

Looks like the ordering is a little be complicated in checksum256. You can try adding --limit 1 to force it to return only one row, then check the returning hash.

@elbowlicker

This comment has been minimized.

Copy link
Author

commented Jan 22, 2019

Looks like the ordering is a little be complicated in checksum256. You can try adding --limit 1 to force it to return only one row, then check the returning hash.

Following is the full parameters I have tried. But it still didn't work.

   { scope: 'inita',
     code: 'inita',
     table: 'user',
     json: 'true',
     lower_bound: '940ade173dce37480f6ab974a2e235f69e5128ba3804574ab10877bc5f503ee7',
     upper_bound: '940ade173dce37480f6ab974a2e235f69e5128ba3804574ab10877bc5f503ee8',
     index_position: '2',
     encode_type: 'hex',
     key_type: 'sha256',
     limit: 1 },
  json: true };

@taokayan

This comment has been minimized.

Copy link
Contributor

commented Jan 22, 2019

How about using the lower_bound and limit only but not the upper_bound?

@conr2d

This comment has been minimized.

Copy link
Contributor

commented Jan 22, 2019

I wrote a patch for fixing this issue (#6591), but it's under review.

@taokayan

This comment has been minimized.

Copy link
Contributor

commented Jan 22, 2019

@conr2d However this might break the existing app that relies on the current logic. @heifner do you have any idea on #6591 ?

@conr2d

This comment has been minimized.

Copy link
Contributor

commented Jan 22, 2019

@taokayan This doesn't change how sha256 hash to be stored in multi_index, but only changes how to search rows with given hash value. (My patch is only related to chain_plugin) I think changing the way to make a query is not breaking existing behavior, because it didn't work in a right way.

@heifner

This comment has been minimized.

Copy link
Contributor

commented Jan 22, 2019

I'm going to let @arhag review it. He is more familiar with that code.

@7-of-9

This comment has been minimized.

Copy link

commented Jan 23, 2019

+1

I've had to use a i128 key instead of sha256 key to be able to retrieve a single row by secondary index, which is a quite sub-optimal.

(Would be very helpful if when this fix is merged, the docs could also get an example of indexing by key_type sha256, with intuitive values working.)

@wangyilin1987

This comment has been minimized.

Copy link

commented Apr 26, 2019

mark

@jasonbert

This comment has been minimized.

Copy link

commented May 6, 2019

I believe this stackexchange post is relevant to this discussion. It's quite a nuisance that the value returned from a checksum256 property on a table row can't be directly used with the sha256 secondary index key type. At the moment the value requires processing before it can be used.

@gaboesquivel

This comment has been minimized.

Copy link

commented May 16, 2019

IMO the API code be responsible for reversing the sha for you, so that you can query using the sha256 string as is.

@cppfuns

This comment has been minimized.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.