repository tool

[Rinse Lemstra]

I would like to ask for your feedback on the idea described below. A prototype of the concept is already available.

The idea is to develop a repository tool based on the “contract-first” principle. The database schema is designed and maintained in a contract (schema.json). The physical database can then be generated from this contract.

An application is distributed with the corresponding schema.json. At runtime, the tool can analyze the existing database, compare it with the schema defined in the contract and, if necessary, perform the required database migrations.

The tool consists of two components:

1. A GUI for maintaining the database schema, including the ability to import an existing database and generate a schema.json from it.

2. A database engine that is included in the application. At runtime, this engine checks whether the existing production database matches the supplied schema and, if necessary, automatically performs the required migrations.

In this way, schema.json becomes the central contract between the application and the database. Both database creation and database migrations can be managed and executed based on this contract.

https://github.com/TimeWriterNL/repotool/raw/refs/heads/main/repository-tool_4.zip

[Andreas Reichel]

Greetings Rinse!

From my perspective, if this works reliably, it would be very useful.

We have various installations of the same DB applications, with 4 schemas and different versions/patch levels.

Right now, we have to maintain a table $SCHEMA.version_info for each schema, which holds the deployed version history.

When we find a version not sufficient, we have to update via schema_version.sql incrementally. Which means: 1) we need to trust  $SCHEMA.version_info and 2) we need to maintain a schema_version.sql for each version.

If your solution does this more robust, it would be great.

The caveat was: I would not want to deal with any JSON files and I would expect that I can feed in a SCHEMA DDL.sql and then you create that automatically.

The other question I have: I though liquibase solved the same problem already? How is yours different?

Best and cheers

Andreas

--
You received this message because you are subscribed to the Google Groups "H2 Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email to h2-database...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/h2-database/a474bd56-5529-4b3e-b3fc-49aa8b0a633dn%40googlegroups.com.

[Rinse Lemstra]

I am a strong advocate of the “contract-first” principle, similar to the approach used for APIs.

There are, of course, many ways to achieve the same goal. Liquibase has chosen a different approach.

The caveat was: I would not want to deal with any JSON files.

The GUI will deal with it.

I would expect that I can feed in a SCHEMA DDL.sql.

Since both schema.json and schema_ddl.sql can ultimately describe the same database structure, converting between the two formats should, in principle, not be a problem.

I have noted this as a feature request.

Op maandag 24 augustus 2026 om 15:13:12 UTC+2 schreef Andreas Reichel: