How can i use Postgres or any other database for ignition config data?

Is it possible to use Postgres or any other database to save the ignition config data.
by default, ignition is using SQLite with config.idb. can we change this default?

No.

And in v8.3, database storage for config is going away completely.

Ok, what's the plan to store this config data then?
when is 8.3 expected?

Config in 8.3 is supposed to be text files, essentially (I don't know if they'll be JSON, XML, YAML, or something else). You'll be able to use version control tools with it. v8.3 is expected to be released early 2025, but I believe they'll have some betas out by the end of the year (hopefully).

1 Like

I believe it's gonna be YAML.

It's not.

1 Like

It's going to be JSON by convention, though each type of config is technically going to be able to choose and be able to store all manner of files.

3 Likes

I'm not sure where I got that from, maybe I just dreamed it.

Will the JSON/markup be diffable?
For example, I've struggled to diff UDT or Tag JSON exports in 8.1 and would not want the config in 8.3 to have the same limitation.

Generally, yes, because it turns out most config resources are a pretty flat key: value pair structure with no deep nesting. They're also generally all sorted in a deterministic way, though again, this is just convention, not strictly defined by the APIs involved.

Maybe it should be a rule? Hopefully with Jidesoft's Alphanumeric comparator?

I'll rephrase. If you follow the happy path for configuration, using JSON, your output will be deterministically sorted, without you having to do anything as an API consumer. If you opt out of that happy path (and choose to take on a lot of extra work yourself), it's up to you to store your resource files in whatever format you feel like.

3 Likes

Ok, makes sense. I just have to wait to see the beta to whine if the deterministic ordering isn't human-friendly. :sweat_smile:

2 Likes

I know it's unlikely to change, but I'm tossing in another vote for something easier to diff than JSON.

Over a year ago I added a json2yaml git textconv rule for all view.json files in my workspace, and it was the best damn thing I could've done.

I can see it now...floods of support calls because someone set up the resource storage for some format some customer "insists" on using. Hopefully there is a large warning urging developers to stay on the "happy" path.

Not customer selectable. This is something a module developer has to choose. (Me!)

I intend to follow the easy path for everything except my EtherNet/IP module's XML configurations. Those will simply be moved entirely to the filesystem, without any compression. They are already deterministically ordered and diff-friendly.

1 Like

Ok, I guess the way @PGriffith worded it, I thought it was selectable on a gateway-by-gateway basis, and was fearing the worst. Since it's by module developers, that makes more sense.