rzo1 opened a new pull request, #215: URL: https://github.com/apache/openjpa/pull/215
Section 3.10.8 scopes the duty to updates "which could potentially affect the result of the query" and lets the provider discharge it "by flushing those entities to the database or by some other means" — the access-path check is exactly that other means. The 4.2.0 line replaced it with "is anything dirty at all", which flushes the whole context before every query in a write-heavy transaction. The justification in that change — that the access path "may miss dirty entities reachable via navigation (e.g. `o.customer.spouse`)" — turns out to be **false for JPQL**: `traversePath()` already registers every hop, and the reproducer committed with it passes unchanged with the access-path check restored. It was **true for the Criteria API**, where `evalAccessPaths()` looked at roots and their immediate joins only, with a standing `TODO -- need to handle subqueries`. So this fixes the access path at the source — implicit joins, joins of joins, fetch joins, subquery types, and joins made on a correlated join — instead of flushing everything. Review also found JPQL collection-valued paths omitted element and key types, which the Criteria side already registered; that asymmetry is closed too. The `IgnoreChanges` override is replaced by the distinction 3.10.8 itself draws: `Query.setFlushMode(AUTO)` set explicitly on the query now overrides `openjpa.IgnoreChanges=true`, while an inherited flush mode keeps honouring it — the option is documented and recommended together with `FlushBeforeQueries=true` in the optimisation guide, so silently disabling it was not an option. The two prohibitions in that section already hold and are now pinned by tests: `isActive()` covers "no transaction active", and an unjoined context cannot reach the flush because `SynchronizationType.UNSYNCHRONIZED` is rejected outright. No compatibility flag: the broadened behaviour exists only on the unreleased 4.2.0 line, so nothing released changes. The migration note is rewritten instead. 18 new tests in `persistence/flush`. Verified 1332 tests with no failures on this branch and on pristine master, on both the Derby and H2 profiles. Each production hunk is discriminated by reverting it alone; reverting the whole diff does not discriminate, because master flushes everything anyway and so masks the incomplete access paths — seven of the eighteen are therefore regression guards, as the commit message says. -- 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]
