OutSystems Platform brings solution deployment improvements on how the platform handles errors during deployments, in order to make deployments even more reliable.

The following sections describe such improvements:

Handling Database Upgrade Errors

Typical database upgrade errors are due to changes in the model that are incompatible with the existing database, namely:

  • unique constraint violations when creating a primary key or a unique index over data with duplicate records

  • foreign key constraint violations when foreign keys over attributes with no corresponding entries in the foreign database table

  • foreign key constraint violations when deleting records of static entities that are in use by other database tables

  • database column length violations when reducing the length of a column that contains data longer than the new length

  • database column type violations when changing the datatype of a column that contains data that cannot be converted to the new datatype

  • generic timeouts creating indexes for a database table with a very large number of records

Starting with, any of the above errors abort the deployment of a solution before changing the application meta-model. Furthermore, in SQL Server all DDL statements executed before these errors are reverted as they occur in a single transactions. In MySQL and Oracle, DDL statements issue an implicit commit, thus DDL statements executed before the error are not reverted.

Also the message now contains a link to access detailed error log in case of database upgrade error, and messages were updated for clarity.

Handling Incompatible Dependencies

Incompatible dependencies may occur when deploying a solution via Service Center (Service Center does not validate dependencies prior to the deployment as LifeTime does). Starting with, deployments in production environments consider incompatible dependency messages as fatal errors and abort the deployment with no impact to the running applications. Non production environments have a different behavior and will continue the solution deployments. This behavior can be customized for both production and nonproduction environments. Please contact support@outsystems.com for further details.

External Solution Dependencies

Starting with, solution deployments via Service Center are consistent with the LifeTime deployment behavior and only deploy the modules effectively included in the solution. In prior versions, the platform also deployed solution dependencies (the producers required by the solution). This means solution deployments no longer publish commonly used modules like “Users” and “Rich Widgets”. This also means solution deployments via Service Center are now as fast as deployments via LifeTime. If you need to deploy the dependencies, just include them in the solution.

Other Changes

Up until, when the available Application Objects or Software Units ran out in the middle of a solution deployment (either through Service Center or LifeTime), the deployed applications might end up inconsistent - only some modules from the new application version could end up deployed (those that were able to, before a licensing error happens).
Starting with, Application Objects or Software Units availability are calculated before starting the actual deployment. This means that, when publishing a solution, no modules will be deployed unless all of them can be successfully deployed, avoiding the possibility of inconsistent deployed applications.

What do I do to start using those improvements?

Good news! All you have to do is upgrade to the OutSystems Platform If you have any feedback, please let us know.