Darwin | small Java library that helps applications | Database library

Darwin is a Java library typically used in Database applications. Darwin has no bugs, it has no vulnerabilities, it has build file available, it has a Permissive License and it has low support. You can download it from GitHub.

Darwin is one of our oldest libraries, which we still use extensively - its origins date back to 2007. It allows easy evolution of the data model for your application. Darwin runs migration SQL scripts in a specific dialect according to clearly defined rules. It probably originated much earlier than the open-source variants of Liquibase or FlywayDB. It is also much simpler, but it represents a reliable "Kalashnikov" for us, which is universal and reliable in its simplicity. The library allows you to maintain SQL scripts on classpath, allowing you to create the tables that your application needs, not only for one specific database, but for different ones at once (ie in parallel you can maintain both MySQL and Oracle schema for your universal libraries). Darwin decides which one to apply after starting the application and finding out the database type from the DataSource object. As you further develop your application, you will soon find that the existing table structure does not suit you and needs to be expanded or changed. To do this, all you have to do is to save the so-called patch files in the Darwin folder, containing in your name the version number of the application for which this structure is needed. The next time you start the application, Darwin will compare the current version of your application (ie the one you just started) with the version it last applied to the database schema. If the application version is newer, it finds all patches between the two versions and applies them to the schema one by one. At the same time, Darwin pays close attention to the "transactionality" of changes, and even if the database does not support transaction for schema changes (ie it cannot properly roll back DDL SQL statements), it remembers which SQL statements it actually executed as part of the patch and which did not. Thanks to this, it can start its activity even in the middle of a half-applied patch. This is especially handy in the development phase. The library allows for a modular approach, so it can be instantiated in the application, for example, 20 times for different shared libraries. Darwin also pays great attention to the traceability of everything he has done with your database. All statements he executed at your instruction are logged in its tables with all necessary information such as the date the patch was discovered in the application, the date the patch was applied to the db, the duration of individual SQL statements, any exception that fell out of the database when much more. Darwin also includes a Locker tool that allows you to synchronize tasks within a cluster if a shared database exists. Darwin uses this Locker class to apply SQL patches to only one of the nodes when running the same application on multiple nodes in a cluster at the same time, and the other instances of Darwin obediently wait for the migration to complete. However, you can use the tool for other purposes. For example, we use it relatively actively to control the execution of asynchronous tasks not only within the cluster, but also on one instance of the JVM. For more information see section How to use.