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

PKValue #141

Open
KyGost opened this issue Apr 13, 2022 · 4 comments
Open

PKValue #141

KyGost opened this issue Apr 13, 2022 · 4 comments
Labels

Comments

@KyGost
Copy link
Member

KyGost commented Apr 13, 2022

Representing primary keys as a more concise type than Value, such that stored values are actually hashable and safely unique might be a good idea.

Floats and nulls wouldn't be allowed.

Strings probably wouldn't be allowed?
(?)-- requires allocation, unsized. Either could be allowed or maybe could be converted to a limited size?

@KyGost KyGost added the idea label Apr 14, 2022
@KyGost
Copy link
Member Author

KyGost commented Apr 14, 2022

Reasons why this might not be a good idea:

  • is there much benefit?
  • is conversion cost a concern?

@KyGost
Copy link
Member Author

KyGost commented Apr 14, 2022

Prehaps PKValue should be an alias or a wrapper, without type info.
Stored as [u8; 8] or u64

@KyGost
Copy link
Member Author

KyGost commented Apr 15, 2022

Per #144, implement PKValue as a trait/enum and implement TryFrom<Value>

@KyGost
Copy link
Member Author

KyGost commented Apr 16, 2022

Should be implemented as a trait which gives Into<[u8; 8]> and CAN_PK

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant