diff --git a/docs/source/database-management.rst b/docs/source/database-management.rst index bf0a8bf773..9e4c4c9c0a 100644 --- a/docs/source/database-management.rst +++ b/docs/source/database-management.rst @@ -40,6 +40,11 @@ As a database migration framework, we use the open source library `Liquibase `_ and `Tutorial `_. @@ -75,9 +80,9 @@ Migration scripts structure Corda provides migration scripts in an XML format for its internal node and vault tables. CorDapps should provide migration scripts for the tables they manage. In Corda, ``MappedSchemas`` (see :doc:`api-persistence`) manage JPA Entities and thus the corresponding database tables. So ``MappedSchemas`` are the natural place to point to the -changelog file(s) that contain the changesets for those tables. Nodes can configure which ``MappedSchemas`` are included +changelog file(s) that contain the change-sets for those tables. Nodes can configure which ``MappedSchemas`` are included which means only the required tables are created. To follow standard best practices, our convention for structuring the -changelogs is to have a "master" changelog file per ``MappedSchema`` that will only include release changelogs (see example below). +change-logs is to have a "master" changelog file per ``MappedSchema`` that will only include release change-logs (see example below). Example: @@ -267,7 +272,7 @@ production. .. warning:: A very important aspect to be remembered is that the CorDapp will have to work on all supported Corda databases. It is the responsibility of the developers to test the migration scripts and the CorDapp against all the databases. - In the future we will provide aditional tooling to assist with this aspect. + In the future we will provide additional tooling to assist with this aspect. When developing a new version of an existing CorDapp, depending on the changes to the ``PersistentEntities``, a changelog will have to be created as per the Liquibase documentation and the example above.