You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A common use case is to combine a text search with a timestamp sort. It would be interesting to see whether this library could support a numerical index in addition to a text index without too much rework, or breaking changes.
Problematic part of building this support is that we need possibly write a completely new index implementation, or make smart abstraction of some generic index. In addition the query API will become more complicated since we need to distinguish the types of the fields we query, and need to provide a different API for numbers ("lt", "lte", "ge", "geq" operators).
A silly solution to this problem would be to convert numbers to byte arrays, and see each byte as a string token i.e. This would let us do simple "lt", "lte" queries in the same way as doing prefix searches (i.e. counting three leading 0 zeros in [0,0,0,123] would let us quickly know this number is below or equal to 255).
A better solution would be to implement this thoroughly where we would build a dedicated index for numerical values.
The text was updated successfully, but these errors were encountered:
I think that sorting is better left to the caller that needs to display the results because there are many permutations of sorting requirements. Maybe I am storing dates not timestamps or I want to sort by a field in the document etc etc.
My preference would be for this library to focus on indexing and querying text 👍
A common use case is to combine a text search with a timestamp sort. It would be interesting to see whether this library could support a numerical index in addition to a text index without too much rework, or breaking changes.
Problematic part of building this support is that we need possibly write a completely new index implementation, or make smart abstraction of some generic index. In addition the query API will become more complicated since we need to distinguish the types of the fields we query, and need to provide a different API for numbers ("lt", "lte", "ge", "geq" operators).
A silly solution to this problem would be to convert numbers to byte arrays, and see each byte as a string token i.e. This would let us do simple "lt", "lte" queries in the same way as doing prefix searches (i.e. counting three leading 0 zeros in [0,0,0,123] would let us quickly know this number is below or equal to 255).
A better solution would be to implement this thoroughly where we would build a dedicated index for numerical values.
The text was updated successfully, but these errors were encountered: