Moving from Mendix Studio Pro 8 to 9

Last modified: August 20, 2024

Introduction

Mendix Studio Pro 9 gives you powerful new tools to enhance your apps. For the full list of changes, see the Studio Pro 9 release notes.

Updating from Studio Pro 8 to 9

The following sub-sections explain the steps to take in converting your app from Studio Pro 8 to Studio Pro 9. Mendix recommends first reviewing the Breaking Changes section of the Studio Pro 9.0 release notes as well as our updated System Requirements.

Backing 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.

Upgrading to the Latest Release of Version 8

To upgrade to Mendix 8.18, follow these steps:

  1. Download the latest patch release of Studio Pro 8.18.
  2. Open your app in Studio Pro 8.18.
  3. Allow it to upgrade the app, if necessary.

Reviewing 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.

Saving 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.

Upgrading 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.

Upgrading 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.

Updating 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.

Reviewing and Testing Your App

Finally, review the sections below and ensure that you have made all the changes necessary. Test the app for any unexpected results.

Mendix 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 Runtime API link in our Mendix Runtime API.

Additionally, refer to the Mendix Studio Pro 9.02 Release notes for more Mendix Runtime API change details.

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 DataStorage.EnableDiagnostics to true to check for potential data redundancy issues that might exist in the database.

If any are found, an error like An error occurred while initializing the Runtime: Detected unique constrain 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.

Mendix Object Changed Flag

In Mendix 9.5 and above, when you change an object member, the member state becomes ‘CHANGED’ even if the old value and the new value are the same. This also affects objectHasChanged and memberHasChanged Java actions of the Community Commons module.

For example, you have a committed object $User with $User/Name = 'Alice'. Setting $User/Name to 'Alice' results in the member state becoming ‘CHANGED’ even though the name is the same. Previously, this would have resulted in the member state remaining ‘UNCHANGED’.

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:

For best results with native apps, make sure you have updated the Native Mobile Resources module as described in the Upgrade All Widgets and Modules section above.

Client API Changes

Client APIs that were deprecated and marked for removal in Mendix 9 were indeed removed. Libraries like big.js, react, react-native, and a few others shipped with the Client have been updated to latest version. This might affect your custom and pluggable widgets and to JavaScript actions. Please refer to the Breaking Changes section of the Studio Pro 9.0 release notes for more details.

Native Dependencies

Mendix 9 native apps no longer include non-essential native libraries like react-native-maps, react-native-ble-plx, react-native-geocoder, and others by default. Instead, new functionality of declaring native dependencies for components has been introduced in Mendix 9. Every pluggable widget or JavaScript action must declare which native libraries it uses. This way, native apps can be bundled with only the libraries they need while unnecessary libraries are not included.

If your pluggable widget or JavaScript action uses libraries that require native linking, please update your widgets and actions in order to define those native libraries as dependencies for your components. Read more about native dependencies in Declaring Native Dependencies.

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 Customer will be used for the association, whereas in //Address[Customer_Address/Customer/Lastname = 'Doe'], the rules in Address will 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/Address in a Java action. If an instance of Address is reachable from multiple Customer instances, QE7 would return the instance of Address multiple times. QE9 will return each matching instance of Address only once.

Relevant Mendix Community Posts

Check out how the Mendix community resolves upgrade issues in the following Mendix Community posts:

Read More