Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

https://github.com/CourseOrchestra/2bass

DB schema as code tool
https://github.com/CourseOrchestra/2bass

Last synced: 2 months ago
JSON representation

DB schema as code tool

Lists

README 

        
= 2BASS



image::https://ci.corchestra.ru/buildStatus/icon?job=2bass/dev[link=https://ci.corchestra.ru/job/2bass/job/dev/]

image:https://awesome.re/mentioned-badge.svg["Mentioned in Awesome database tools", link=https://github.com/mgramin/awesome-db-tools]



2bass is a database configuration-as-code tool that utilizes the concept of https://ponomarev.uk/blog/ddl[idempotent DDL scripts].



This is a derivative of link:https://github.com/CourseOrchestra/celesta[Celesta project], in particular, it uses link:https://courseorchestra.github.io/celesta/en/#CelestaSQL[CelestaSQL] as database definition language.



:toc:



image::images/bass_duke.png[,200]



== Current status



This project is in development phase. For binaries see link:https://github.com/CourseOrchestra/2bass/releases[releases], or see <> if you want to build the freshest binary yourself. If you want to contribute (suggestions/feature requests are very welcome!) please feel free to contact any of the contributors.



== How to build from sources



You will need JDK 8 and Maven in order to build 2bass. If you want to run tests during the build, you will also need Docker to be installed. To build without compiling and running the tests, run



 mvn package -Dmaven.test.skip=true



The result of the build will be `target/2bass--bin.zip` file.



== How to install and run



Prerequisites: JRE 8. Unzip `target/2bass--bin.zip` file and make `bin` folder availiable on system path.

Run `bass` command and check its output.



== How to use

* Usage example is available at https://github.com/inponomarev/2bass-demo.



* Usage:



 bass  



* Available commands are:



** `validate`         Parse and validate SQL scripts (with no connection to database).

** `init`             Initialize system `bass` schema.

** `plan`             Generate and show DDL execution plan for review / manual exectution.

** `apply`            Build or change database structure.

Sync your actual DB structure with the desired structure described in your SQL files.

All the ALTER commands are calculated and executed automatically. You may run `apply` without running `init` previously



* Options are:



 [--debug] [--jdbc.password=] [--jdbc.url=]

        [--jdbc.username=] [--outputFilePath=]

        [--propertiesFile=] [--score.path=]



**   `--debug`                      Debug mode: show exception stack traces

**   `--jdbc.password=`   Database password

**   `--jdbc.url=`             JDBC connection URL

**   `--jdbc.username=`   Database user name

**   `--outputFilePath=`      Path to write scripts to (for `plan` command)

**   `--propertiesFile=`      Path to .properties file with options (options set

                                in command line have higher priority)

**   `--score.path=`          Path to SQL scripts



* Write and modify your database schema using CelestaSQL, which is in fact the plain old DDL.

Е. g. you may use CREATE TABLE for table definition, and then simply add/modify columns in the script when you need it,

no 'ALTER' commands in schema definition script. You may also use `EXEC NATIVE` blocks when you need to insert

database-specific code. See our https://github.com/inponomarev/2bass-demo[demo project] and https://courseorchestra.github.io/celesta/en/#CelestaSQL[CelestaSQL documentation].



* Example outputs for `apply` and `plan` commands:



image::images/3_update_success.png[,600]



image::images/2_plan.png[,800]



=== If something goes wrong during database migration



Sometimes bass is not able to perform the migration fully automatically. In this case will see the following:



image::images/3_update_failure.png[,800]



and for further details you should look at the contents of the `bass.schemas` table. In `message`

field you will see the error that prevented the automatic migration. The meaning of numbers in `state` column is

as following:



* **0** -- schema created/migrated successfully, will not attempt to migrate unless the checksum of DDL script is changed.

* **1** -- schema is currently in process of migration.

* **2** -- migration error (see `message` column for details).

* **3** -- force migration, regardless of DDL script checksum. In case of success the status will become **0**.

* **4** -- never migrate this schema, regardless of DDL script changes.



Normally in case of errors you should:



1. Write and execute an ad hoc migration script.

2. Change schema status to 3.

3. Re-run `bass apply`.