jdaugherty commented on PR #16515: URL: https://github.com/apache/grails-core/pull/16515#issuecomment-6072635910
@borinquenkid 1. No. GORM for MongoDB and the in-memory datastore don't apply `id composite: [...]`. The entity keeps its generated `id`, so `persistentEntity.identity` is set and `get` runs the restricted query. 9d47b98435 adds a multi-tenant entity mapped with `id composite:` to both specs: read as another tenant, `get`, `read`, `exists` and `getAll` find nothing, and the `load` proxy fails to initialize. Against the previous `GormStaticApi` the same features fail, because `get` returns the other tenant's instance. The `identity == null` check guards a mapping that does produce a composite identity. Among the GORM datastores only Hibernate does, and it overrides these methods, so this PR leaves it alone. A JPA-annotated entity with two `@Id` properties would be the other way to get one, but it does not compile. 2. Both behaviors are what GORM for Hibernate already does on 7.0.x, because its `get` of a multi-tenant entity also runs a query. With Hibernate 5, the `AUTO` flush mode flushes before that query. With `COMMIT`, a saved but unflushed instance is not found by `get`, `count` or a finder. Without a tenant, `get` and `load` throw `TenantNotFoundException`. Queries and finders on a multi-tenant MongoDB or in-memory entity already throw `TenantNotFoundException` without a tenant. So the change makes their lookups by id behave like Hibernate's and like their own queries, and what it fixes is `get` returning another tenant's instance. That is why I opened it against 7.0.x, with upgrade note 19 covering both points. @matrei, it's your call: if you'd rather it land in the next minor, I'll retarget it. -- 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]
