Summary

Prepare the range-based DB list mappings for future commit-wide JDBC batching by removing local read/result dependencies and introducing stable logical list-element tracking for Audit mappings.

This change does not implement commit-wide batching yet. It establishes the semantic prerequisites needed so that later batching can keep PreparedStatement batches pending without depending on intermediate database visibility or DML result counts.

Changes

NonAuditListTableMapping

• Removed the physical list-index offset read from the planning phase.
• List delta planning now remains in logical/relative coordinates.
• The current physical offset is resolved only when SQL indexes are materialized for database execution.
• Existing overflow handling and forced zero-based behavior are preserved.
• The generic two-stage disjoint index-shift strategy remains unchanged and is treated as an ordering requirement rather than a batching blocker.

AuditListTableMappingWithRanges

• Removed DML result-count dependencies from entry removal and clear processing.
• Made current-version and older-active-row predicates disjoint where necessary.
• Reworked index shifting so that:
  • older active rows are copied with INSERT ... SELECT,
  • historical rows are closed separately,
  • current-revision rows are moved directly,
  • no subsequent DML generation depends on an earlier update count.

LogicalListPlan

Added and integrated an Audit-specific sparse logical list plan.

The plan:

• represents unchanged original elements compactly as OriginalRange(start, length);
• tracks original elements by immutable originalIndex;
• assigns plan-local identities to newly added elements;
• never uses list values as element identity;
• therefore correctly supports non-unique EMF lists;
• preserves identity across Add, Remove, Set, and Move operations;
• keeps Set values as overrides on the existing logical element identity;
• moves the exact same logical element rather than resolving it by value;
• splits and merges original ranges as required;
• does not materialize the original list or read original values from the database.

Memory usage is proportional to changed/split segments rather than the original list size.

Audit Move processing

The LogicalListPlan now runs lockstep with the existing range-delta processing.

As a result, Audit Move operations no longer require a synchronous getValue(sourceIndex) database read.

Moved elements are handled as follows:

• unchanged original element: resolved through its stable originalIndex and copied using INSERT ... SELECT;
• Set element: uses the explicit overridden value while retaining its original identity;
• Added element: uses its explicit delta value and plan-local identity.

This removes the remaining local Audit read-after-pending-write barrier relevant to future batching.

Shared range writer

The common AbstractRangeListDeltaWriter received only minimal neutral extension points needed by the Audit plan integration.

Branching behavior remains unchanged and continues to use its existing value/base-resolution path.

Compatibility

• No public API changes.
• No schema changes.
• No class renames.
• No JDBC batching implementation yet.
• No changes to Branching batching semantics.
• Non-unique EMF list semantics are preserved; equal values are never treated as identical list entries.

Validation

• git diff --check passes.
• The changed classes compile successfully with the Eclipse incremental compiler.
• All H2 tests pass.

Follow-up

The next step is to design commit-wide batching and scheduling support, with the goal of maximizing PreparedStatement locality while minimizing the in-memory lifetime of pending batches.