Skip to content

Fix #721, Add batching to flat file imports - #845

Merged
whilo merged 2 commits into
replikativ:mainfrom
harismh:harismh/batch-imports-#721
Jun 28, 2026
Merged

Fix #721, Add batching to flat file imports#845
whilo merged 2 commits into
replikativ:mainfrom
harismh:harismh/batch-imports-#721

Conversation

@harismh

@harismh harismh commented Jun 27, 2026

Copy link
Copy Markdown
Contributor

SUMMARY

Println for migrate/import-db mentioned batching transactions but wasn't actually implemented, leading to file watcher crashes #721. PR implements actual batching with a configurable var and sets the default to 10k per the #721 (comment). Used a var instead of a config map to maintain the fn signature, but I could go either way.

I did see #727 and ultimately it's the better long-term solution. But, I do feel adding just batching keeps the scope smaller and the other changes can be worked in later.

Checks

Feature
  • Related issues linked using fixes #721
  • Integration tests added
  • Documentation added

ADDITIONAL INFORMATION

@whilo
whilo merged commit 32b4012 into replikativ:main Jun 28, 2026
whilo added a commit that referenced this pull request Aug 12, 2026
`update-max-tx` and `*import-batch-size*` are not new: they date from
af6fe0c, are on origin/main, and are in tags back to v0.3.6-SNAPSHOT.
This branch did not delete them — it moved them to
`datahike.migrate.legacy` along with the single-file reader they serve.

The two are not equal in standing, though, and the move treated them as
if they were. CHANGELOG line 129 announces one of them by its
fully-qualified name:

  **Imports are now batched** — `datahike.migrate/import-db` now imports
  flat-files in configurable batches (`datahike.migrate/*import-batch-size*`,
  default `10000`) instead of one transaction. ([#845])

So `*import-batch-size*` goes back to `datahike.migrate`. Its value is
passed to `import-db-legacy` as an argument rather than read there, so it
is read at the call site and therefore inside the caller's `binding`
scope; `import-db` still detects a legacy dump and routes to it, so a
binding written against that CHANGELOG entry behaves exactly as before.

Two things ruled out, both recorded in the docstring so they are not
retried: it cannot be defined in `legacy` and referred to from here,
because `datahike.migrate` already requires that namespace and the
reverse require is a cycle; and it cannot be aliased, because an alias is
a NEW var — `(binding [datahike.migrate/*import-batch-size* 5] …)` would
set something nothing reads, which is a silent no-op where today's
behaviour is a loud compile error.

`update-max-tx` stays in `legacy`, deprecated: never documented anywhere,
and `max-tx` is maintained by `load-entities` now. CHANGELOG records the
move. Line 129 needs no correction — with the var back, it is true as
written.

The test that covered this was decorative. It bound the var and then
asserted only on the imported datoms, which are identical at any batch
size, so it passed whether or not the binding was plumbed through. Two
candidate observables do not work either: transaction entities, and the
datoms' `:tx` — a legacy import PRESERVES the tx from the dump (that is
what `update-max-tx` is for) and every datom in the fixture carries
536870913. The batch sizes handed to `transact` are the honest signal.
Red-checked by bypassing the binding: `got [12]` against `[5 5 2]`.

JVM 3022/35076/0, Node 252/1511/0.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants