I started a Liquibase XML-editor, using liquibase-core, featuring support for the Language Server Protocol, meaning it can be used in any editor or IDE supporting LSP: Eclipse, VSCode, VIM, IntelliJ, cloud-based IDEs like Theia and more: https://github.com/Treehopper/liquibase-lsp/
Even though I already find it pretty useful for my own use, I would consider this a PoC: The concept that I tried to proof is the viability of applying Liquibase XML change logs to an in-memory database on every key-stroke, resulting in an interactive feedback loop, without needing to save or press a button.
This turned out to work even better than I expected. At least with the change logs that I typically work with.
Because I re-use Liquibase and H2/JDBC features (plus the wonderful LemMinX project) this provides pretty powerful validation features, with a relatively small amount of new code.
I am posting this to “Development” though, because this is still quite fresh, and because I am wondering if any of you ever anticipated Liquibase being used like this.
Also, I encountered a couple of challenges in using Liquibase for an interactive editor. Some of those, I worked around in this sub-module: https…sorry-new-users-can-only-put-2-links-in-a-post.
Those and others, would best be implemented in a clean way in Liquibase itself, though. The ones I know, I have listed here: https://github.com/Treehopper/liquibase-lsp/labels/liquibase
If there is some interest in this, I’d be happy to contribute a few changes. I think those would benefit not only this, but every future interactive editor based on Liquibase.
Hi Max! I really like this quite a bit. Are you developing for a different database platform and just using H2 locally to validate the changelog as you write it?
Hi Pete. Exactly, I only use H2 for validation and because it is fast and simple to integrate in a Java project.
In the project I am currently in, I have to support SQLServer, Oracle and PostgreSQL, and I don’t want to maintain three different branches of the same changelogs. So in theory, I’d have to validate the changelogs against those three. Though, I think it would be better to add validation features to warn against using DB-specific types and such, and leave the proper translation to Liquibase. What do you think?
If you are not developing DB agnostic changelogs, you could enhance the project to accept a JDBC URL as a configuration parameter.
I have created a ticket [1] to add support for using different database platforms for validation. It’s not my top priority, as H2 works fine for me, but it would be a relatively small change and a very welcome contribution, if you are interested.
BTW: Since the project is using LSP, the server part may be deployed on the same machine as the DB, and the editor could connect remotely. That might be a good idea, if you don’t want to run a heavy DB on your local machine.
[1] h***s://github.com/Treehopper/liquibase-lsp/issues/16 (weird that this forum prevents me from posting links to GH issues…)
Another consideration would be using a json snapshot of the database to perform the validation instead of an H2 database. Then the platform consideration kind of goes out the window because the snapshot model should be consistent across variants and contain the same info you’re using from H2.
If I could make that work, you could just have a snapshot of your latest production database (or some other meaningful database) that is used for validation of new changes without actually having to connect to that database.
So you think we could import the snapshot, and run the validation on top of that model?
Sounds interesting, and might also solve some other use cases:
a legacy schema that hasn’t been initially created with Liquibase (maybe a corner case)
long history of changelogs that would slow down parsing significantly
As I understand Liquibase this would require a few changes though. First of all, we would need to be able to initiate parsing without a Liquibase DB being present [1] (or a Mock DB). Second, we would need to be able to specify the baseline-model to be used for validation. Or is this already possible?
If you have a good understanding of how this feature could look like, please feel free to create a new ticket on liquibase-lsp outlining the required changes.
