This documentation describes how to work with Orcas.
For this documentation, the Orderentry example is used, for information on how to install and run orcas refre to the correspponding instructions of your favorite build-tool:
With Orcas all tables (and other database objects) are stored in plain text files. These then place typically be placed in a version control along with the other sources of a project.
The task of Orcas is to read these files, compare them with an existing database schema and execute the necessary schema changes.
For example in the orderentry example there is a table named “categories”.
It is defined in a file called “categories.sql”:
If the new column “image_location” is inserted:
Orcas will add the new column to the database.
In the same way you would perform other changes like:
- Change default values
- Add or delete constraints
- set “not null” or remove it
- Create tables
- Create foreign keys
- Change data type/length.
Deleting parts of the data model
There are two changes that are blocked by default:
- Delete Column (unless the column is empty)
- Delete Table (unless the table is empty)
Both changes run through, if the table is empty (or in columns although if only null values are present). In the Orderentry example it will work for now (because all the tables are empty initially). But if you write data into the tables, then this leads to an error message.
Notices: If an error occurred no changes are made to the schema, thus it can’t happen that a transfer was only “half” performed.
This lock can be avoided with the so-called “dropmode”. In the Orderentry example you need to change the entry dropmode=”false” into dropmode=”true” in the build.xml.
It’s generally not recommended to activate the “dropmode”, because in some instances (import of an old version/ Merge error / renaming) it can lead to data loss. Therefore “dropmode” should at least not be enabled on production databases.
Extension of the data model
In typical products 90-95% of the changes to the data model are extensions, which can usually be easily implemented with Orcas.
Modification of the data model
Changes that do not directly refer to data (eg to expand the Index by a column) are usually also easily to handle with Orcas.
But as soon as a data migration is required, Orcas can no longer recognize the necessary changes by a simple adjustment. These include the use cases Rename a table and Rename a column.
Orcas offers two ways to perform such changes to the data model.
In this possibility SQLPlus scripts on any database schema only be executed exactly once. The Orderentry example is so arranged, that all scripts under orderentry\db\skripte are handled like this.
With liquibase a change statement in the database change log is usually necessary for any change to a scheme. Orcas offers the possibility to reduce these change instructions to a minimum.
With both variants you have to mind, there is a possibility developers forget to create a specificone-time-script or database-change-log-entry. In these cases the dropmode is very important to prevent a loss of data.
Furthermore you always have to change the table scripts, too.