nitrite_support v2.0.4

• Maintenance release: raised nitrite dependency to ^2.0.4.

nitrite_spatial v2.0.4

• Maintenance release: raised nitrite dependency to ^2.0.4.

nitrite_hive_adapter v2.0.4

• Maintenance release: raised nitrite dependency to ^2.0.4.

nitrite_generator v2.0.4

• Maintenance release: raised nitrite dependency to ^2.0.4.

nitrite v2.0.4

• Fixed field.eq(x) / field.within(..) on an array (list) field silently matching nothing when the filter runs as a collection scan. Array membership is matched element-wise on the index path but was matched by whole-value equality (deepEquals) on the collection-scan path, so results depended on whether an index existed or was chosen by the planner. Combined with the 2.0.3 planner change (mirror of nitrite-java #1266) — which correctly relegates the non-winning-index filter to a collection scan — an AND of an indexed array eq and a bounded range on a second indexed field left the array eq running as a collection scan, where it matched no documents. EqualsFilter and _InFilter now match an array/Iterable field by element containment on the collection-scan path, mirroring applyOnIndex.

nitrite_support v2.0.3

• Maintenance release: raised nitrite dependency to ^2.0.3.

nitrite_spatial v2.0.3

• Maintenance release: raised nitrite dependency to ^2.0.3.

nitrite_hive_adapter v2.0.3

• Maintenance release: raised nitrite dependency to ^2.0.3.

nitrite_generator v2.0.3

• Maintenance release: raised nitrite dependency to ^2.0.3.

nitrite v2.0.3

• Fixed a type-comparison crash (e.g. InvalidOperationException: Could not compare type int to String) when an AND filter combined a filter on one indexed field with filters on another, differently-typed indexed field matching a different number of fields (e.g. a single-field index next to a compound index). The query planner picked the best-matching index candidate per field independently but accumulated filters from every candidate it visited into one shared set instead of keeping only the winning index's filters, so filters from an unrelated index leaked into the scan of the chosen index. The planner now selects a single best-matching index and only keeps that index's own filters for the index scan. Mirrors nitrite-java issue #1266.