...
- When configuring the repository for your SQL scripts, you may now specify which schema a script applies to in a multi-schema project. This will allow the Deployment Packager to limit it's change detection & recovery capabilities to only those schema that are impacted by the scripts being processed during that packager run.
- For example: If there are 30 schema in your project, but there are only scripts for 4 of the schema in this packaging run, then packager will be limited to the 4 relevant schema for that packaging run (instead of all 30 schema). This can shorten the packager run time. This only works if all of the scripts for that packaging run have the schemaName property set in the metadata.properties files in their folders.
- To configure, set the value of a 'schemaName' property in the metadata.properties file for a specific directory. The value can be one schema name or a comma separated list of schema names. Do not put quotes around the schema values. Use the casing that matches how the schema is listed in your datical.project file. For example: schemaName=SCHEMA1. Please see this page → Using the metadata.properties file
- Setting this property does not affect script execution in any way. It is used internally by the Deployment Packager to limit the scope of operations by schema.
- We recommend using either schemaName property OR backup on demand:
- If you are using backup mode "always", then the schemaName property will limit the schema list to the relevant schemas for three aspects of packager: backup, restore, and snapshot.
- However, if you are using backup mode "on demand" then the schemaName property will limit the schema list to the relevant schemas for only one aspect of packager: snapshot. When you set backup to "on_demand" all of the schemas in the project will be backed up and restored, the schemas for backup/restore will NOT be limited based on the schemaName property.
2. If packaging scripts in the "ddl" folder (when using Fixed Folders) or packageMethod=convert (when using Flexible Folders) is slow, consider using the optional "ddlExcludeList" property in the deployPackager.properties file to exclude certain object types from the snapshots that are used for before and after comparisons with ddl scripts. If you are packaging stored logic objects in their recommended corresponding packaging folders (such as packaging function scripts in the "function" folder, and packaging procedure scripts in the "procedure" folder) then you do NOT need to have those object types in the snapshots used by the convert method when packaging ddl scripts in the "ddl" folder. Excluding stored logic object types from the snapshots used in the "ddl" folder can improve performance, especially if you have a lot of stored logic objects in your database.
...
- If you want to use static on demand backups, we recommend running Datical DB versions 5.6 or higher.
- Note that if you use backup on_demand, you will NOT get the full benefits of using the schemaName property in the metadata.properties file:
- If you are using backup mode "always", then the schemaName property will limit the schema list to the relevant schemas for three aspects of packager: backup, restore, and snapshot.
- However, if you are using backup mode "on demand" then the schemaName property will limit the schema list to the relevant schemas for only one aspect of packager: snapshot. When you set backup to "on_demand" all of the schemas in the project will be backed up and restored, the schemas for backup/restore will NOT be limited based on the schemaName property.
4. For Oracle, use the "parallel" property for Oracle backup/restore as described in this document → Using the required deployPackager.properties file
...