Skip to content

Conversation

@CascadingRadium
Copy link
Member

  • Change FieldIndexingOptions from int to uint64 for platform independent behaviour.
  • This facilitates serialization of FieldIndexingOptions which is being introduced as part of zapx v17

CascadingRadium added a commit to blevesearch/zapx that referenced this pull request Nov 21, 2025
- Introduces fieldsOptions in the zap file segment to store indexing
options for every field.
- Decouples indexing logic from Bleve, allowing zapx to independently
understand each field’s indexing configuration.
- Enables the merger to identify which options were used to index a
field without consulting the index mapping.
- Adds metadata to the zap file format, making it a breaking change for
version 17.
- Requires blevesearch/bleve_index_api#76

---------

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Copy link
Member

@abhinavdangeti abhinavdangeti left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this necessary?

CascadingRadium added a commit to blevesearch/zapx that referenced this pull request Dec 16, 2025
- Introduces fieldsOptions in the zap file segment to store indexing
options for every field.
- Decouples indexing logic from Bleve, allowing zapx to independently
understand each field’s indexing configuration.
- Enables the merger to identify which options were used to index a
field without consulting the index mapping.
- Adds metadata to the zap file format, making it a breaking change for
version 17.
- Requires blevesearch/bleve_index_api#76

---------

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
@CascadingRadium
Copy link
Member Author

Why is this necessary?

Hi @abhinavdangeti, since v17 we persist FieldIndexingOptions in the segment and varint-encode it, so the type must have a stable, architecture-independent size. In Go, int is platform dependent (32-bit vs 64-bit), which would make the on-disk representation unsafe. Using uint64 guarantees a fixed layout, makes the bitmask intent explicit, and effectively gives us up to 64 flags (instead of potentially 32), allowing future options without changing the storage format.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Development

Successfully merging this pull request may close these issues.

3 participants