Delta patch files are executed if one or more objects in the corresponding source file have been identified as requiring to be updated. If any of the objects in the same source file needs to be created or dropped Lure will first execute all such creates and/or drops. (Note that Lure will not drop to recreate an object if a delta patch file exists.) If subsequently at least one object is identified that needs to be updated then all statements in the corresponding delta patch file will executed. Lure assumes that the developer has taken the responsibility for writing patch statements to update all existing objects as required.
To be clear, Lure will not execute a patch file when all corresponding objects are up to date in the database.
The order in which delta patch files for the same object type are executed (or at least considered for execution) is not defined.
Versioned patch file names contain a version number and Lure uses this version number to determine when to execute the patch file. Conversely this means that unless Lure has access to the source code of the previous versions of the tables Lure cannot use versioned patch files correctly.
Lure supports three modes in which it can get access to previous versions of table source code. These modes are configured using the variable
patch.file.history.mode in the Lure config file. When this variable is set to either
P4 then Lure retrieves the required previous versions of the table source code directly from a Subvbersion or Perforce repository respectively. This is the simplest and most powerful setting. Alternatively this variable can be set to
LOCAL in which case Lure expects the previous versions of the source files to be made available locally within the Lure source code tree corresponding to the settings in the Lure config file.
Before executing a versioned patch file Lure first determines whether the table in the database is up to date corresponding to the latest source code in the file. If the table is up to date then no patch files will be executed for this table. Otherwise Lure will proceed to determine whether the current source of the table in the database matches the source code in the source file with version corresponding to the patch version number. For example, given a patch file with name
EMPLOYEE.table.lsql.r35.lpatch Lure will compare the current DDL of the table in the database with revision 35 of the file
EMPLOYEE.table.lsql as obtained from the Subversion/Perforce repository. Only if the database and file source match will Lure execute the corresponding versioned patch file.
At any point in time there could more than one versioned patch files for a table. Lure will cycle though all such versioned patch files (from lowest to highest version) and determine whether to execute the versioned patch file. In this way Lure can automatically handle tables that are at various different patch levels or versions.
The order in which versioned patch files of the same version number are executed (or at least considered for execution) is not defined.