Interface FlushSettings

All Known Subinterfaces:
AvailableSettings
All Known Implementing Classes:
Environment
public interface FlushSettings
Settings related to flush behavior.
See Also:

  • Field Details

    • FLUSH_QUEUE_TYPE

      static final String FLUSH_QUEUE_TYPE

      Specifies the ActionQueue implementation to use. Valid values are defined by QueueType:

      • "graph" (default) - Uses the graph-based ActionQueue implementation, which handles planning automatically based on defined constraints (foreign key dependencies, unique keys, ...).
      • "legacy" - Uses the traditional ActionQueue implementation, which requires hard-coded ordering and manual sorting of actions
      Since:
      8.0
      See Also:
      API Note:
      The legacy implementation remains available by explicitly setting this property to "legacy".
      Default Value:
      "graph"

    • ORDER_BY_FOREIGN_KEY

      static final String ORDER_BY_FOREIGN_KEY
      Whether to order operations by foreign-key as part of graph-based flush planning.
      Since:
      8.0
      See Also:
      Default Value:
      true

    • ORDER_BY_UNIQUE_KEY

      static final String ORDER_BY_UNIQUE_KEY
      Whether to order operations by unique-key as part of graph-based flush planning.
      Since:
      8.0
      See Also:
      Default Value:
      true

    • DEFERRABLE_EDGES_IGNORE

      static final String DEFERRABLE_EDGES_IGNORE

      Controls whether deferrable constraints should create dependency edges in the flush graph.

      Assuming a constraint is deferrable -

      When true (default) - Hibernate expects the database will handle constraint checking at commit - Hibernate doesn't need to worry about execution order for these constraints - Result: Fewer edges → simpler graph → potentially better execution order

      When false - Add deferrable constraints as graph edges even though DB can defer them - Hibernate still controls execution order - More conservative (works even if DB doesn't actually defer)

      Note this simply creates edges. Whether we decide to break these edges when a cycle is detected is still controlled by DEFERRABLE_AVOID_BREAK. The information is sometimes useful even though we may not break these edges.

      Since:
      8.0
      See Also:
      Default Value:
      true

    • DEFERRABLE_AVOID_BREAK

      static final String DEFERRABLE_AVOID_BREAK

      Controls whether deferrable constraints can be broken (nullified + fixup UPDATE) to resolve cycles.

      Assuming a constraints is deferrable -

      When true (default) - Avoid breaking deferrable constraints if possible - Prefer breaking non-deferrable constraints in cycles - Preference achieved by assigning a higher cost to breaking these edges - Only break deferrable constraints if no other option exists. If the database can defer the constraint, why break it? Let the database handle it.

      When false - Deferrable constraints can be broken just like any other nullable constraint - If cycle breaking is needed, deferrable constraints are fair game

      Since:
      8.0
      See Also:
      Default Value:
      true

    • GRAPH_DEFER_IDENTITY_INSERTS

      static final String GRAPH_DEFER_IDENTITY_INSERTS

      Whether the graph-based action queue should defer IDENTITY inserts into the normal flush plan.

      When false (default), the graph queue preserves legacy behavior and executes non-delayed IDENTITY inserts immediately so generated identifiers are visible after persist().

      When true, IDENTITY inserts are planned with the rest of the flush and generated identifiers are resolved through graph-generated value handles.

      Since:
      8.0
      See Also:
      Default Value:
      false