v0.2.62
LATESTRETRIES THE ADAPTER'S WAY, CHUNKED FIRST LOADS
Three things the founder asked for after running 0.2.61 on his own project. Connection retries: every dbt adapter already carries a retry key in profiles.yml, so DVT now reads that same key — retries, retry_count and retry_delay, connect_retries, num_retries, duckdb's nested one — for its own extraction, load, direct and statement connections, with the adapter's own default when the profile is silent, and the hub shows every spelling as one field, Retries. Four Oracle models that died together on an i/o timeout would have retried once and landed. Chunked first loads: chunk_column and chunk_size split a big table's first load into value ranges moved one at a time, on both lanes, so peak memory is one chunk; federation_memory_limit in dvt_project.yml caps DuckDB's memory for the compute and the cache spills under the project's own .dvt/tmp. And every run, build, seed and exec line now speaks in DVT's words — what happened, how many rows, how long — never naming the data mover.
ADDED
- ▸Connection retries on every DVT door — extraction, load, the direct hop, statements — driven by each adapter's own profiles.yml key (retries, retry_count + retry_delay, connect_retries, num_retries, retries.connect_attempts) with the adapter's default when unset; engines with no such key read a plain retries that dbt ignores. A connect failure prints 'oracle did not answer (i/o timeout) — retry 1/2 in 3s'.
- ▸The hub's Connections form carries every engine (the MySQL family, StarRocks and Exasol join) with its retry key under one label, Retries; the profiles.yml key stays the adapter's.
- ▸chunk_column + chunk_size on a federated model: a first load (f_table, or an f_incremental's first run / --full-refresh) is probed for count, min and max of the column and moved in equal-width value ranges — one parquet part per chunk with the same pinned types on the compute lane, full-refresh then appends on the direct lane.
- ▸federation_memory_limit in dvt_project.yml caps DuckDB's memory for the federation compute; the cache always spills under the project's own .dvt/tmp.
CHANGED
- ▸Run, build, seed and exec lines never name the data mover: the result token reads [150000 rows in 13.55s] (it was [SLING 150000 in 13.55s] [150000 rows inserted]), and the messages read 'extraction failed', 'load failed', 'direct load failed', '[direct]', 'DVT's data mover is not installed — run dvt sync'. dvt sync and dvt debug, whose subject is the binary, still name it.
- ▸A chunked first load states its plan on the console — 'qa_chunk__pg_compute: 150000 rows → 3 chunks (50,000 rows each, by value range) on id' — so chunk_size can be tuned from what the run shows.
- ▸A sling fatal that named its cause ('could not connect … connection refused') was reported as a crash with advice to retry; it is now reported as that fatal.
Get it: pip install dvt-core==0.2.62 · wheels on PyPI for macOS (arm64 + x86_64) and Linux x86_64, Python 3.10–3.14 — the full platform matrix.