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

allow more JSON values, fix i64 special case #2383

Merged
merged 1 commit into from
May 1, 2024
Merged

Conversation

PSeitz
Copy link
Contributor

@PSeitz PSeitz commented Apr 30, 2024

This changes three things:

  • Reuse positions_per_path hashmap instead of allocating one per
    indexed JSON value
  • Try to cast u64 values to i64 to streamline with search behaviour
  • Allow top level json values to be of any type, instead of limiting it
    to JSON objects. Remove special JSON object handling method.

TODO: We probably should also try to check f64 to i64 and u64 when
indexing, as values may get converted to f64 by the JSON parser

@PSeitz PSeitz requested a review from fulmicoton April 30, 2024 08:11
This changes three things:
- Reuse positions_per_path hashmap instead of allocating one per
  indexed JSON value
- Try to cast u64 values to i64 to streamline with search behaviour
- Allow top level json values to be of any type, instead of limiting it
  to JSON objects. Remove special JSON object handling method.

TODO: We probably should also try to check f64 to i64 and u64 when
indexing, as values may get converted to f64 by the JSON parser
@PSeitz PSeitz merged commit 92b5526 into main May 1, 2024
4 checks passed
@PSeitz PSeitz deleted the allow_json_vals branch May 1, 2024 10:08
PSeitz added a commit to quickwit-oss/quickwit that referenced this pull request May 6, 2024
use JSON for concat fields instead of concatenating text fields.

With quickwit-oss/tantivy#2383 we support now
non-object values on the root in the JSON field.
As a nice side-effect, this will make regular JSON fields more powerful.
Instead only for nested types, JSON is now also useable for flat mixed-type fields.

Closes: #4924
PSeitz added a commit to quickwit-oss/quickwit that referenced this pull request May 6, 2024
use JSON for concat fields instead of concatenating text fields.

With quickwit-oss/tantivy#2383 we support now
non-object values on the root in the JSON field.
As a nice side-effect, this will make regular JSON fields more powerful.
Instead only for nested types, JSON is now also useable for flat mixed-type fields.

Closes: #4924
PSeitz added a commit to quickwit-oss/quickwit that referenced this pull request May 6, 2024
use JSON for concat fields instead of concatenating text fields.

With quickwit-oss/tantivy#2383 we support now
non-object values on the root in the JSON field.
As a nice side-effect, this will make regular JSON fields more powerful.
Instead only for nested types, JSON is now also useable for flat mixed-type fields.

Closes: #4924
PSeitz added a commit to quickwit-oss/quickwit that referenced this pull request May 6, 2024
use JSON for concat fields instead of concatenating text fields.

With quickwit-oss/tantivy#2383 we support now
non-object values on the root in the JSON field.
As a nice side-effect, this will make regular JSON fields more powerful.
Instead only for nested types, JSON is now also useable for flat mixed-type fields.

Closes: #4924
PSeitz added a commit to quickwit-oss/quickwit that referenced this pull request May 13, 2024
use JSON for concat fields instead of concatenating text fields.

With quickwit-oss/tantivy#2383 we support now
non-object values on the root in the JSON field.
As a nice side-effect, this will make regular JSON fields more powerful.
Instead only for nested types, JSON is now also useable for flat mixed-type fields.

Closes: #4924
PSeitz added a commit to quickwit-oss/quickwit that referenced this pull request Jun 8, 2024
use JSON for concat fields instead of concatenating text fields.

With quickwit-oss/tantivy#2383 we support now
non-object values on the root in the JSON field.
As a nice side-effect, this will make regular JSON fields more powerful.
Instead only for nested types, JSON is now also useable for flat mixed-type fields.

Closes: #4924
philippemnoel pushed a commit to paradedb/tantivy that referenced this pull request Aug 31, 2024
This changes three things:
- Reuse positions_per_path hashmap instead of allocating one per
  indexed JSON value
- Try to cast u64 values to i64 to streamline with search behaviour
- Allow top level json values to be of any type, instead of limiting it
  to JSON objects. Remove special JSON object handling method.

TODO: We probably should also try to check f64 to i64 and u64 when
indexing, as values may get converted to f64 by the JSON parser
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

Successfully merging this pull request may close these issues.

2 participants