Deploying resources to databases

The following resource types are all deployed "to" a database - i.e. deploying each of them results in documents being inserted into a database:

• Alerts
• Flexible Replication
• Partitions (as of version 3.17.0 - see Database Rebalancer)
• Query Partitions (as of version 3.17.0 - see Database Rebalancer)
• Schemas (as of version 3.11.0)
• Temporal (for configuring bi-temporal support)
• Triggers (as of version 3.6.2)
• View schemas (for configuring e.g. SQL access)

Until version 2.9.0 of ml-app-deployer, support was only provided for deploying these resource types into the application's main content database. And the files for each resource type were expected to be found in the root configuration directory. So you could have a setup like this:

/alert/configs/my-config.json
/databases/content-database.json
/flexrep/configs/my-config.xml
/view-schemas/my-schema.json
/temporal/axis/my-axis.json

And that worked just fine when you only wanted to deploy these resources to your application's main content database.

Version 2.9.0 of ml-app-deployer now provides support for deploying these resources into any database. The key is where the resource files are located. Instead of being located in the top-level directories above, they must be placed under a directory under "databases" that is named after the database that the resources are deployed to.

Note that for triggers, the name of the database in the path should be the name of the triggers database. For example, if you have two triggers databases named "triggers1" and "triggers2", you could deploy different triggers to them via the following directories:

./ml-config/databases/triggers1/triggers
./ml-config/databases/triggers2/triggers

What to do when your database name isn't known at build time

Starting in version 3.16.0, an alternate mechanism is provided for determining the database that the resources are associated with. When your database name isn't known at build time - likely because it's determined by property values - you won't be able to have a directory named after the database. Instead, you can name the directory to match the name of the database file, minus its extension, that defines the database with which you want to associate the resources.

For example, let's say you have a database file named "my-database.json" with the following in it:

"database-name": "%%someProperty%%"

To associate a trigger with this database - whose name we don't know at build time - we create the following directory and file:

src/main/ml-config/databases/my-database/triggers/my-trigger.json

ml-app-deployer will see the directory name of "my-database" and first check to see if that's a valid database in MarkLogic. In our case, it's not. So ml-app-deployer will then look for a file whose name, minus its extension, is "my-database". It finds out "my-database.json" file. It then reads in the contents of that file, replacing tokens, and determines that the name of the database is whatever the value of "someProperty" is.

Example

If you want to deploy an alert configuration to a database named "my-other-content-database", you'd have the following setup:

/databases/my-other-content-database.json (the name of this file doesn't matter)
/databases/my-other-content-database/alert/configs/my-config.json

Each directory named after a database then acts as a "mini" configuration directory. Similar to "alert", you can also have "flexrep", "temporal", and "view-schemas" directories under "my-other-content-database", with each containing resources that will be deployed to my-other-content-database.

Note that for temporal and view-schemas, the resources are deployed to the schemas database associated with the content database. So if you have two content databases that share the same schemas database, you only need to define temporal and view-schemas for one of those databases.

A note about schemas

Support for schemas was added in 3.11.0. Schemas aren't actually resources, as defined by the Manage API. But this technicality is ignored in favor of the convenience of being able to load different sets of schemas into different schemas databases via this convention.