Restore configurable insert-method selection - #152
Conversation
defaultInsertMethod was parsed from presets, JSON, config files, and -D but discarded by buildDriverConfig, so every workload kept its hard-coded InsertRequest.Method and invalid values passed silently. Resolve an effective insert method once per run and apply it to every load: - New run-scope typed parameter --insert-method (plus INSERT_METHOD env, -e, and config run.insertMethod) is the highest-precedence override. - The driver-level defaultInsertMethod (preset, raw JSON -d, config drivers[N], -D insertMethod/-D defaultInsertMethod) is restored through buildDriverConfig and validated with driver.ParseInsertMethod. - Unsupported-for-driver values fail before loading starts via driver.ResolveInsertMethod over the capability matrix. - The workload-authored method remains the fallback when no override is set. Precedence: typed CLI > env > config > driver default > workload default. Closes #133
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
A bare -d preset was leaking its defaultInsertMethod into the effective method, silently replacing the workload's hard-coded method. Presets are now driver+URL templates and carry no insert-method opinion; only --insert-method, -d/-D insertMethod/defaultInsertMethod, raw JSON, and config drivers[N] may override. Also require a resolved driver type before validating the method and capability-check the driver-set value through ResolveInsertMethod. Closes #133
Retarget blocked: runtime config design decision required#152 cannot be mechanically detached from skipped #150/#151 and retargeted to current A dry rebase of only this PR's commits ( Current A maintainer must choose among functionally different designs:
Two further policy choices affect observable behavior:
Merging this PR as-is updates #151's blocked branch, not Please choose the runtime transport, preset-default policy, and validation timing, then restack only the selected #152 behavior on current |
Summary
Restores the configurable insert-method selection that
buildDriverConfighad been silently discarding.defaultInsertMethodwas parsed from presets, raw JSON, config files, and-D, but every workload kept its hard-codedInsertRequest.Methodand invalid values succeeded.What changed
--insert-method(plain_query,plain_bulk,columnar,native) with process envINSERT_METHOD,-e INSERT_METHOD, and configrun.insertMethod— the highest-precedence user override.defaultInsertMethodrestored: preset/JSON/drivers[N].defaultInsertMethod/-D insertMethod/-D defaultInsertMethodnow flows intoconfig.DriverConfig.InsertMethodand is validated at driver-build time viadriver.ParseInsertMethod.driver.ResolveInsertMethodvalidates the value and rejects methods the selected driver does not serve — before loading starts.Bench.Insertapplies the resolved method to every load request (tpcc/tpcb/simple/tpch/tpcds all route through it); a zero value keeps the workload's own method.driver.InsertCapabilities) and help/schema enumerate all values includingcolumnar.Precedence (highest → lowest)
--insert-method(CLI >INSERT_METHODenv >-e> configrun.insertMethod)defaultInsertMethod(-D/JSON > configdrivers[N]> preset)Tests
driver.ResolveInsertMethod/SupportsInsertMethod/InsertMethodsunit tests (valid, invalid, unsupported).benchresolution precedence test + a fake driver proving the resolved method reachesDriver.Insert(and that the workload default is kept when unset).run.buildDriverConfigresolution tests (valid/invalid/unsupported +-D insertMethodaliases).Closes #133