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

Support Partial Indexes #177

Closed
ethanfrey opened this issue Dec 13, 2020 · 2 comments
Closed

Support Partial Indexes #177

ethanfrey opened this issue Dec 13, 2020 · 2 comments
Labels
blocked Waiting for something before we can start storage plus

Comments

@ethanfrey
Copy link
Member

Related to #163 (modifying same code logic, good to work on them one after another)

Currently in storage plus, indexes always return a byte key. One common pattern from SQL systems, to save access, is to only index a part of the data.

For example, if we wish to always know the first and last height of all open proposals as an O(1) query, we could create and index (status, height), and assuming #163, then prefix scan over Status::Open to find the first/last height. However, this requires maintaining an index for all the other statuses, we do not care about.

However, and index like INDEX height WHERE status = Status::Open (to borrow from SQL syntax) would only index currently open proposals and record their height, which is exactly what we need and no more.

Design:

  1. Indexing function is currently defined as: index: fn(&T) -> Vec<u8> (or with Support composite keys on secondary indexes (multi-index) #163 index: fn(&T) -> K)
    Define partial indexer as index: fn(&T) -> Option<Vec<u8>> (or with Support composite keys on secondary indexes (multi-index) #163 index: fn(&T) -> Option<K>)

  2. Create two constructors
    The first one new can work as is, and assume a complete index.
    Add a second constructor that takes a partial indexing function.
    Internally, you can either wrap the complete indexer as a partial indexer that always returns Some(x), or store the two as enum variants.

  3. Update save and remove and test them

@ethanfrey ethanfrey added this to To do in Contract development via automation Dec 13, 2020
@ethanfrey ethanfrey modified the milestone: v0.9.0 Aug 17, 2021
@ethanfrey ethanfrey added the blocked Waiting for something before we can start label Aug 17, 2021
@ethanfrey
Copy link
Member Author

Blocked: waiting for a clear use case or three to implement. Not just something I think "may be useful someday"

@ethanfrey
Copy link
Member Author

Haven't yet come across a real use case. Closing unless this becomes important in a real project

Contract development automation moved this from To do to Done Dec 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocked Waiting for something before we can start storage plus
Projects
No open projects
Development

No branches or pull requests

1 participant