Tags: nitrite/nitrite-java
Tags
Make the sorted-page cost guard survive a slow runner The v5.1.0 tag build failed on the Windows runner and nowhere else, on this guard: fat 14.5 ms against lean 2.7 ms, a 5.4x ratio through a 4x threshold, with the index-ordered sort in place and working. `release.yml` gates on Build succeeding, so the Maven Central publish was skipped and 5.1.0 never shipped. The threshold was not the problem, the shape was. The guard compares a sorted page over lean documents against one over fat documents at the same row count, so that the index walk - identical in both - cancels and only the decode differs. But a page of 20 fat documents costs more to return than a page of 20 lean ones no matter how the order was decided, and that difference is the floor of the ratio. On this machine it is noise; on the Windows runner it was most of the measurement. Asking for one row instead of twenty shrinks that floor twentyfold while leaving the discarded-row decode at full size. Measured here: 0.56x with the index-ordered sort against 85x without it, so a 3x threshold now sits five times clear of a passing run rather than seven-tenths of the way to a failing one. Test-only. Also dates the 5.1.0 changelog entry correctly. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
feat!: remove the no-op distinct find option BREAKING CHANGE: removed `FindOptions.withDistinct()` (both overloads), `FindOptions.distinct()` and `FindPlan.distinct`. The flag never affected the result set. A find never returns the same document twice, and the `or` sub-plan union in ReadOperations has always applied DistinctStream unconditionally - so FindOptimizer wrote the flag onto the FindPlan and nothing ever read it back. Callers passing `FindOptions.withDistinct()` can drop it with no change in results. `DistinctStream` itself is unchanged and still used for the `or` union. Also adds CollectionOrDuplicateTest, which pins the set-union behaviour of an `or` filter for the no-index, one-indexed-branch and all-indexed-branch cases. nitrite-java was already correct here; the same test found real duplicate defects in nitrite-rust and nitrite-flutter, and is added to keep the three implementations honest. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
fix: restore CopyOnWriteArrayList for unique and text index value lists The #1260 index rework (4.4.0) switched the per-key `List<NitriteId>` value used by unique and full-text indexes from CopyOnWriteArrayList to a plain ArrayList mutated in place. MVStore serializes dirty page values on a background thread, so mutating that list after it is written to the map races with the serializer, throwing ConcurrentModificationException (and could corrupt the id list, later surfacing as a spurious UniqueConstraintException) even under single-threaded use. Restore CopyOnWriteArrayList for these classic list-valued index paths so each mutation swaps the backing array atomically and the background serializer always sees a stable snapshot. The composite-key layout for non-unique indexes (the actual #1260 optimization) is unchanged. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
PreviousNext