Package com.kingsrook.qqq.backend.core.jobs.plans
package com.kingsrook.qqq.backend.core.jobs.plans
-
ClassDescriptionWhat a running chunk can see and do: its job and chunk rows, its lease, the fenced checkpoint write, and the cooperative check (pause, cancel, drain, lost lease) that plans call at safe points - between pages or steps.The CHUNKED plan for streamed ETL processes (spec section 2.4, plan 1): bulk insert, edit and delete, record actions and data processes.What a durable job chunk hands to the process steps it runs, on the thread that runs them: - a provided transaction: StreamedETLExecuteStep loads into it instead of opening (and committing) its own, so the chunk's rows and its DONE mark commit together (SAME_TRANSACTION: exactly once); - a row-error sink: transform and load steps report each failed row (file row number or record key, field, code, message) so the job can record them in jobs_row_error.Which job chunk this scope runs: the parts of an effect's idempotency key, and the process whose effect declarations apply.The chunk's cooperative check (pause, cancel, drain, lost lease), run between pages; it throws JobInterruptedException to stop the chunk.One failed row.Thrown from a cooperative check to stop a chunk at a safe point: the job was paused or cancelled, this pod is draining, or the lease was lost.Why the chunk stopped.How a job's work is split into chunks and how one chunk runs.Chooses the plan for a job (spec section 2.4): - streamed ETL whose extract is ExtractViaQueryStep, launched over a filter or record ids: CHUNKED by key range (TABLE_FILTER / RECORD_IDS); - streamed ETL whose extract is BulkInsertExtractStep, launched with an upload: CHUNKED by file rows (STORAGE_FILE); - retry of failed rows: CHUNKED over just those rows (ROW_SET); - ATOMIC semantics, and every other process: the STEPS plan.The STEPS plan (and ATOMIC): run any process's backend steps from its launch point onward, as one chunk, with frontend steps skipped (their values were collected before launch).