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

Indexed values should be required to conform to IndexComparable #176

Open
dimitribouniol opened this issue Mar 29, 2024 · 1 comment
Open

Comments

@dimitribouniol
Copy link
Member

This protocol should return an agnostic representation of a comparable structure in a format that the datastore natively understands. Take a look at foundation db for inspiration, as their binary key paths could be a good format. However, since the goal is to still have human readable files on disk, the default format could be an array of enum primitives to be sorted accordingly? One benefit to Comparable is the ability to add new sorting capabilities, so some investigation should be placed into supporting that well.

@dimitribouniol
Copy link
Member Author

dimitribouniol commented Apr 2, 2024

Some ideas:

  • A series of comparable components separated by .
  • A component can itself be a series of components being wrapped in [ and ]
  • Little-end comparison is the default (ie. for strings)
  • Big-end comparison prefixed with # (ie. for numbers of variable length)
  • Strings marked with ", and \ is used as a de-facto escape character (ie. \.. even if there is no special meaning to .)
  • Hex numbers/strings prefixed with x
  • Probably need a symbol for "nil", both one that appears before and one that appears after other members. (< and >?)
  • Floating point numbers can use ,, or we define another symbol.
  • Might need additional symbols for different forms of string normalization
  • Each component class has a stable sort relative to one-another.
  • Unknown component classes should also have a stable sort for backwards compatibility.

There should be a binary compatible coding scheme that uses the least amount of space.

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

No branches or pull requests

1 participant