codeconsole commented on PR #16297:
URL: https://github.com/apache/grails-core/pull/16297#issuecomment-5531215439

   All six addressed, one isolated commit each, every fix pinned by a test 
verified to fail without it.
   
   | commit | finding |
   |---|---|
   | `0fa6561` | Legacy `engine: mapping` incompatible |
   | `ded9ea7` | `IN` on to-one associations not coerced |
   | `9a8506d` | Negated criteria bypass coercion |
   | `19a146a` | `updateAll` writes the declared representation |
   | `5bf4e5c` | Empty assigned String id cannot be deleted |
   | `0f1bc9b` | `idGeneration.adoc` contradicts the new default |
   
   Two notes where the investigation diverged from the report.
   
   **The legacy engine needed two changes, not one.** `generateIdentifier` was 
the wrong place: `storeEntry` overwrites `_id` with the declared-type 
identifier immediately afterwards, so a fix there has no effect. The read side 
was separately broken — `createDBObjectWithKey` builds the by-key filter and 
passed the hex String straight through for `hasStringIdentifier`, so even 
correctly stored documents were unfindable. Both now go through the id mapping 
while the domain still sees its declared type.
   
   **Negation.** `Domain.where { id != hex }` compiles to `NotEquals`, an 
ordinary `PropertyCriterion` that the existing preprocessing already covered, 
so my first test passed with the fix reverted and proved nothing. The reported 
form is the one that breaks: coercion now lives in a helper that recurses 
through junctions, and `not { eq 'id', hex }`, `findAllByIdNot(hex)` and a 
nested to-one association criterion all fail without it.
   
   The `IN` fix resolves the entity whose identifier mapping governs the 
criterion — the associated entity for a to-one, the queried entity for its own 
identity — and coerces each value after `getInListQueryValues` unwraps it, so 
`child in [childInstance]` and `findAllByChildInList(..)` both work.
   
   `grails-data-mongodb-core` is at parity with `8.0.x` locally: the only 
failures are the two pre-existing `MongoDatastoreLifecycleSpec` cases, which 
also fail on an unmodified checkout here.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to