Mendix Studio Pro 9 and Mendix Studio 9 give you powerful new tools to enhance your apps. For the full list of changes, see the Studio Pro 9 and Studio 9 release notes. If you want to upgrade an existing Studio Pro 8 or Studio 8 app to its respective 9 version, please check the information below:
- If you are upgrading your app in Studio from Mendix 8 to 9, see Upgrading from Mendix 8 to 9 for Studio below.
- If you are converting your app from Studio Pro 8 to Studio Pro 9, see Changing Your App Before Upgrading to Studio Pro 9 below.
2 Upgrading from Mendix 8 to 9 for Studio
2.1 Turn On RCSI for MS SQL Server
In order to improve performance and reduce the chance of deadlocks, Mendix 9 requires MS SQL Server to be used with Read Committed Snapshot Isolation (RCSI) turned ON.
During the synchronization stage, Mendix 9 will perform a check for the RCSI status and could abort the process if it is not ON and the database user lacks the necessary privileges to do so automatically.
3 Update from Mendix 8 to 9 for Studio Pro
The following sub-sections explain the steps to take in converting your app from Mendix 8 to Mendix 9. We recommend you first review the Breaking Changes section of the Studio Pro 9.0 release notes as well as our updated System Requirements.
3.1 Back Up Your App
Make sure that you have either committed your latest changes to Team Server, or created a backup of your local app before you start the conversion.
3.2 Upgrade to the Latest Release of Version 8
It is technically required for you to upgrade your app to Mendix 8.12 first to be able to update it to Mendix 9. However, we recommend you update to the latest version of Mendix 8: 8.18.
To upgrade to Mendix 8.18, follow these steps:
- Download the latest patch release of Studio Pro 8.18.
- Open your app in Studio Pro v8.18.
- Allow it to upgrade the app, if necessary.
3.3 Review Your Mendix 8 App
Review your app in combination with the sections below and assess if further action needs to be taken before upgrading to Mendix 9.
You should run your app, test all functionality, and ensure it works without error. If you app uses app services, you should remove them before upgrading as app services are deprecated in Mendix 9.
You should also fix any depreciation warnings you see both in development in Studio Pro, as well as in the runtime using your console and browser console.
3.4 Save Your Version 8 App
Backup or commit your app so that you can return to it if necessary.
Your app is now ready to be upgraded to Mendix 9. You can now close the app in Studio Pro 8.
3.5 Upgrade Your App to Version 9
Open your app in Studio Pro 9 and allow Studio Pro to update your app to version 9. Mendix will upgrade your app for you automatically.
Review all error messages and messages about deprecated items and make changes where necessary.
3.6 Upgrade All Widgets and Modules
To minimize the chance of problems, you should update all widgets and other Marketplace modules used by your app to the latest version.
Check if there is a newer version of your modules available in the Marketplace. Read the version release notes in the Marketplace to see whether you need to perform specific actions when upgrading.
Be sure to update these key widgets, resources, and actions:
In general you should not remove and reimport modules, unless this is recommended in the release notes. If you do remove and reimport them, you may lose data or configuration related to the module.
3.7 Update Atlas Module (Optional)
Mendix 9 comes with a new Atlas theme including new page templates and building blocks. To get this theme, you can download the Atlas Core, Atlas Web Content and Atlas Native Content module packages from the Marketplace.
3.8 Review and Test Your App
Finally, review the sections below and ensure that you have made all the changes necessary. Test the app for any unexpected results.
Congratulations! Your app has been successfully upgraded to Mendix 9 and you can continue working as normal.
4 Runtime API Changes
Most of the Java API calls that were deprecated in Mendix 8 have been removed. If you were still using such methods in your Java actions, you must replace or delete them. To check which calls were depreciated, click the Mendix 8 Server Runtime API link in our Runtime API Documentation.
Additionally, refer to the Mendix Studio Pro 9.02 Release notes for more Runtime API change details.
4.1 Changes to Database Uniqueness
Before Mendix 9, Mendix could ensure data uniqueness using either the Mendix runtime or by relying on the database engine itself. Starting with Mendix 9, Database will be the only option.
If your app is still using Mendix runtime for uniqueness validation, then you should set the custom runtime setting
true to check for potential data redundancy issues that might exist in the database.
If any are found, an error like An error occured while initializing the Runtime: Detected unique constraing violation… will be logged. To solve this, your app will have to be prepared before moving to Mendix 9. You can obtain the tools you need by submitting a support request.
5 Testing Native Mobile Apps
To test and preview native mobile apps in Mendix 9, you must download the Mendix 9 version of the Make It Native app:
- Download Make It Native 9 for Android in the Google Play Store
- Download Make It Native 9 for iOS in the Apple App Store
6 Client API Changes
Client APIs that were deprecated and marked for removal in Mendix 9 were indeed removed. Libraries like
7 Native Dependencies
Mendix 9 native apps no longer include non-essential native libraries like
8 XPath Query Engine 9
Mendix 9 contains a new XPath query engine called query engine 9 or QE9, replacing the current engine called query engine 7 or QE7. There are a few changes in functionality between the query engines:
If an association is navigable from both sides, both entities can have access rules defined which declare the readability of the association. For such associations, QE9 will always use the entity on the left of the current XPath to determine accessibility. For example: in the query
//Customer[Customer_Address/Address/City = 'Rotterdam'], the access rules defined in
Customerwill be used for the association, whereas in
//Address[Customer_Address/Customer/Lastname = 'Doe'], the rules in
Addresswill be used for that same association. In QE7 the behavior was not well defined.
QE9 has been written to follow the least privilege principle strictly when retrieving data. This might cause less data to be visible to end-users.
While not allowed by Studio Pro, it was possible to use a non-boolean attribute as a constraint in a Java action, for example
//Address[City]. QE7 accepts such queries but, depending on the database, it may give unexpected results. QE9 will reject such queries.
While not supported or documented, it is possible to use a query like
//Customer/Customer_Address/Addressin a Java action. If an instance of
Addressis reachable from multiple
Customerinstances, QE7 would return the instance of
Addressmultiple times. QE9 will return each matching instance of