Repository navigation
fix: bring back the 8.0.0 rules that 8.0.1 reverted by mistake (8.0.2) - #1004
Conversation
…ery engine
The user decided on 2026-10-06 that search('"foo bar"') matches the adjacent
phrase on every engine, as MariaDB, MySQL and SQLite always did, and 8.0.0
shipped that on PostgreSQL too. 8.0.1 bound the 7.x value again, so PostgreSQL
returned 'trump donald' and 'donald john trump' for "donald trump". The e2e
pair now runs on every engine with a fulltext index: the exact term returns
only documents holding the phrase (notSearch excludes only those, except on
MongoDB, whose notSearch is a regex over the raw term), and a term without
quotes keeps matching any word in any order. The PostgreSQL unit bindings
expect the phrase quotes and the 'or'-joined words of 8.0.0 again.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
8.0.0 matched search('"foo bar"') as the adjacent phrase on PostgreSQL, as
MariaDB, MySQL and SQLite always had, and the user confirmed on 2026-10-06
that this is the intended behaviour on every engine. 8.0.1 took the 7.x
any-order match for a regression and bound the term in single quotes again.
Dropping that override hands the prepared term back to the query builder,
which keeps an exact term's double quotes for websearch_to_tsquery(). The
7.4.1 word splitting (foo/bar and foo,bar search both words) still runs
first, so that fix stays intact. UPGRADE.md and CHANGELOG.md (8.0.2) say
8.0.1 reverted the phrase match by mistake.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to PostgreSQL quoted searches are intended to match adjacent phrases, while unquoted searches match any term; separate searches require every term in any order. The reviewed code and test expectations align, with no specific merge-blocking concern identified. Pre-merge checks |
|
…vent rules again
The user decided these 8.0 rules stand, and 8.0.1 reverted them as if they
were regressions (decisions 10-01, BUG-11 approved 10-07, re-confirmed
10-12):
- increase/decreaseDocumentAttribute() refuse a fractional change, max or min
on an integer attribute, and a change of 0 or less throws Exception\Type
(BUG-11: catch (DatabaseException) must see it);
- numeric operators refuse a fractional limit on an integer attribute,
while numeric text such as power('2') stays accepted;
- the UID description names the characters Key accepts (period, hyphen,
underscore, none of them leading), not 7.x's narrower wrong text;
- an update does not re-validate stored values it leaves unchanged, for
every attribute type (J4C-011), so a narrowed range or enum never blocks
an update of another attribute, while a value the update writes is held
to the new rule;
- document_purge fires after the outermost commit and never for a write
that rolled back.
The tests 8.0.1 rewrote go back to their 8.0.0 expectations. A new
DocumentPurgeTest case pins the 10-08 decision that stays: the cache purge
runs inside the write's transaction, so a cache failure rolls the write back
and no purge event fires.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ception\Type again The user decided on 10-01 that the library refuses a fractional change, max or min on an integer attribute (Appwrite rounds the bounds itself), and BUG-11, approved on 10-07, made a change of 0 or less throw Exception\Type so that catch (DatabaseException) sees it. 8.0.1 handed fractional values to the engine again (rounded on MariaDB/MySQL, truncated on MongoDB, an error on PostgreSQL) and threw \InvalidArgumentException. This takes back the 8.0.0 checks in Documents and the Memory/Redis bound comparison. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ers again
The user decided on 10-01 that operators refuse fractional bounds on integer
attributes like increase does, with whole floats compared exactly, and that
numeric text such as power('2') stays accepted. 8.0.1 replaced those checks
with 7.x's numeric-only ones. Validator\Operator is the 8.0.0 validator
again; numeric text keeps passing.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
8.0.0 corrected the UID description to the rule Key enforces (period, hyphen and underscore, none of them leading). 8.0.1 returned 7.x's text, which leaves out periods and hyphens and so tells callers a wrong rule while acceptance stayed the same. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ated again 8.0.0 (J4C-011) stopped re-validating the stored values an update leaves unchanged, because a value stored under older or looser rules then failed every later update of any attribute and could not be repaired. 8.0.1 validated them again and kept the leniency for object values only, so a narrowed range or enum blocked unrelated updates once more. The user decided the 8.0 rule stands for every type: a value the update writes is still held to the current definition. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
8.0.0 fired document_purge after the outermost transaction committed, so no listener ever hears of a write that rolled back. 8.0.1 fired it just before the commit. The user decided the 8.0 order stands. The cache entry itself is still purged inside the write's transaction (the 10-08 decision that keeps a cache outage from committing a write with a stale entry), and the DocumentPurgeTest case added with the tests pins both. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
CHANGELOG.md gains the full 8.0.2 section and marks each reverted 8.0.1 entry. UPGRADE.md states the 8.0.0 rules for fractional counters, operator limits, stored-value validation and document_purge again, and notes that 8.0.1 reverted them by mistake. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The 8.0.0 OperatorTests came back with the operator rules, and with them the engineFamily() helper that 8.0.1 had added there went away, although the float binding test in DocumentTests still calls it. The helper now lives in DocumentTests next to its only caller. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Why
8.0.1 (#1002) restored 7.4.1 behaviour wherever 8.0.0 had changed it. Six of those changes were deliberate 8.0.0 changes the maintainer had already decided on, not regressions. 8.0.2 brings all six back. Everything else in 8.0.1 stays: the link rule,
authorizeCreate()/authorizeUpdate(), float binding, relationship selects, query messages,containsAll(),orderRandom()with a cursor, and the MongoDB write-conflict retries."foo bar"matches the adjacent phrase, as on every other engineincrease/decreaseDocumentAttribute()refuse a fractional change,maxorminon an integer attribute withException\TypeException\Type, whichcatch (DatabaseException)catches\InvalidArgumentExceptionpower('2')stays acceptedUIDdescription names every character it accepts (period, hyphen, underscore)document_purgefires after the outermost commit, never for a rolled-back write. The cache entry is still purged inside the transaction (2026-10-08 decision)What changes
Builder\Postgres::compileSearchExpression(), and the R3-09 word splitting (foo/bar,foo,bar) stays. Item 2 is inTrait\Documents, with the Memory/Redis bound comparison. Item 3 is inTrait\Documents. The other items areValidator\Operator(4),Validator\UID(5),Validator\Structure/ObjectValue(6) andTrait\Transactions(7).8.0.2section and marks each reverted 8.0.1 entry. UPGRADE.md states the 8.0.0 rules again and notes that 8.0.1 reverted them by mistake.Tests (fail-first)
All of these were written first and failed on
main(8.0.1):DocumentTests, run on every engine with a full-text index. An exact term returns only the phrase, withnotSearch()excluding only the phrase. A term without quotes matches any word in any order. On 8.0.1 PostgreSQL returned 4 rows instead of 2.FractionalBoundTest,FractionalOperatorLimitTest,IncreaseDecreaseTest,IncreaseValueTest,NumericUpdateGuardsTest,OperatorLimitTest,OperatorValidatorTest,RedisAdapterPathsTest,DocumentPurgeTestandSearchTermTest, plus e2eOperatorTestsand the counter cases inDocumentTests. Each file failed on 8.0.1 (8, 2, 3, 17, 1, 6, 2, 1, 21 and 17 failures).StoredValueRevalidationTestnow asserts that a narrowed range or shrunk enum leaves the stored value in place and lets the update through, and that writing a refused value still fails.QueriesCompatibilityTestasserts that the UID description matches what the validator accepts.DocumentPurgeTest::testACachePurgeFailureRollsTheWriteBackAndFiresNoPurgeEventpins the 10-08 rule that stays: the cache purge runs inside the transaction, so a cache failure rolls the write back and no event fires.🤖 Generated with Claude Code