SAX Text Catalog Converter
Moving Your SAX Prompt Binder From V1 to V2 Without Breaking a Wire
- catalog_json
So you built a nice prompt binder with SAX Text Catalog V1 - a dozen named prompts inside one node, routed to output slots, no rewiring when you switch scenes. Then V2 turned up with shared catalogs, 10,000 items and set composition, and now you want your old library inside it. This node is the moving van. It just isn't a van that drives itself.
What it is
SAX_Bridge_Text_Catalog_Converter sits in SAX/Bridge/Utility and converts V1 catalog data into a new or existing shared V2 catalog, leaving your original V1 node and every link out of it untouched. V1 stays exactly as it was; V2 is a separate, independently maintained thing. Nothing forces the migration - the converter is for the day you decide you want the same prompt library available in three different workflows.
The reason you'd bother: V1 stores its items inside the node, so the node travels with the workflow. V2 stores items in a catalog on the ComfyUI server, so any workflow on that machine can point at the same library. Once you've built real prompt furniture - a negative block you reuse everywhere, a dozen hair and outfit descriptors - retyping it per workflow gets old fast.
How it works, and the bit that trips people
Here's the thing to internalise before you click anything: the button does the conversion; queueing the node does not. There are two distinct paths through this node and only one of them has side effects.
The UI path is the real one:
- Put the converter in the same graph as your V1 node.
- Use the V1-source button to point at that node and capture its current data. That JSON lands in the
v1_jsonwidget. - Choose a destination - type a name into
catalog_nameto create a new catalog, or pick an existing saved catalog from the list. - Press the registration button. A V2 node referencing that catalog is added to your graph, with only the newly imported set enabled. Wire its
textoutput wherever your old wiring went.
The queue path just returns JSON. catalog_json is the converted document, useful as an export or a backup, and it creates nothing.
What comes across: every item's name, text and tags including ones no relation uses, and each V1 relation becomes its own component inside a set that preserves order, duplicates and enabled states. What's left behind: the V1 tag dictionary and favourite-tag preferences, which are UI conveniences rather than catalog data. Item and set IDs are regenerated and references remapped, so nothing can collide with records already in the destination; duplicate set names pick up a numeric suffix. The append is atomic and revision-checked - a conflict or a limit hit leaves the destination unchanged.
Inputs and outputs
Only two widgets, both plain strings.
catalog_name is required and defaults to V1から変換 ("converted from V1"). For a new catalog this is your name for it; there's no file path involved and you can't point it at arbitrary folders.
v1_json is optional and defaults to {} - the capture slot the V1-source button fills. Hand-editing it is possible and generally a bad idea unless you enjoy debugging validation errors.
The output is catalog_json, a STRING. Wire it into a Show Text or a save-text node if you want a copy of the migration sitting on disk. Don't wire it into a V2 node's config_json - that expects a small workflow reference (catalog ID plus rows), not a whole catalog document. If you want it in another ComfyUI install, use the V2 item list's Import, which accepts a catalog document and issues fresh IDs.
Install
ComfyUI Manager → Install via Git URL → https://github.com/so16tm/SAX_Bridge, or:
cd ComfyUI/custom_nodes
git clone https://github.com/so16tm/SAX_Bridge
Restart, then look under SAX/Bridge/Utility. No Python dependencies, no model downloads, nothing to put in models/. Autocomplete++ is optional and only matters if the text you're migrating contains dynamic syntax that needs expanding.
Common issues
"V1 (version 1) only" error. The converter validates the schema version before doing anything, so a V2 document or a mangled paste gets rejected up front. Reload the source node and recapture.
Nothing happens on a second click. Duplicate registration of the same loaded data is deliberately blocked. Reload the V1 source to register another copy - this exists so you don't end up with three near-identical catalogs after an impatient double-click.
A V2 node appeared and your old one still works. That's the design, and it's the best part. Keep both for a week, compare outputs, then delete the V1 node when you trust it. The converter doesn't mutate anything you had.
The appended set looks emptier than the V1 node. V2 trims each text, drops blanks, and joins what's left with newlines. If a relation had trailing whitespace or an empty string, that's expected arithmetic rather than lost content.
Is it worth it
Migrate when the prompt library has outgrown one workflow, and not before. V2 is a big node with a lot of surface; the converter is the least risky part of adopting it - one click, reversible, and it doesn't touch what already works.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| catalog_name | STRING | V1から変換 | — |
| v1_jsonopt | STRING | {} | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| catalog_json | STRING | — |