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 wildcard matching #64

Open
LostKobrakai opened this issue Oct 26, 2022 · 4 comments
Open

Support wildcard matching #64

LostKobrakai opened this issue Oct 26, 2022 · 4 comments

Comments

@LostKobrakai
Copy link
Contributor

Whenever I look at CubDB.select it feels a little strange how much I need to know about sort order, to be able to select e.g. all values for {:some_key, _}. I'm wondering it this couldn't be simplified.

@lucaong
Copy link
Owner

lucaong commented Nov 11, 2022

Hi @LostKobrakai ,
since CubDB data storage is implemented as a B+tree, using the sort order to filter keys is the most performant option. Ultimately, the main thing to know is the Elixir/Erlang term ordering, and that tuples are compared element by element.

That said, I do agree that a good wildcard syntax could be a nice interface. I do not currently have good ideas on a wildcard syntax that would be simpler than the current min_key/max_key, and that could be translated to it, but I would be definitely open to the concept.

@LostKobrakai
Copy link
Contributor Author

I can totally see why things work the way they work right now. I'm however wondering if CubDBcould "hide" the implementation detail by parsing some provided pattern and using the knowledge about sort order to build the mix/max key internally.

@lucaong
Copy link
Owner

lucaong commented Nov 27, 2022

Yeah I see, something like ETS optimizing for “partially bound keys” when using select on an ordered_set.

On one hand I like how min_key/max_key is always optimized, so one does not need to remember which patterns are optimizable and which are not. On the other, the API could be more ergonomic.

@zachallaun
Copy link

Was just thinking about something similar myself and found this issue. I wonder if a library like matcha (https://github.com/christhekeele/matcha) could be leveraged in some way to provide an alternative, still performant select/filter/map for CubDB.

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

3 participants