cubdb icon indicating copy to clipboard operation
cubdb copied to clipboard

Support wildcard matching

Open LostKobrakai opened this issue 2 years ago • 4 comments

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.

LostKobrakai avatar Oct 26 '22 19:10 LostKobrakai

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.

lucaong avatar Nov 11 '22 21:11 lucaong

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.

LostKobrakai avatar Nov 14 '22 10:11 LostKobrakai

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.

lucaong avatar Nov 27 '22 18:11 lucaong

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.

zachallaun avatar Jan 01 '23 17:01 zachallaun