Table of Contents
- How Do I Define Data in Mendix?
- What Is the Difference Between Persistable & Non-Persistable Objects?
- How Does Object-Relational Mapping Work in Mendix?
- How Can I Use Indexes to Improve Performance?
- How Can I Use a Stored Procedure with Mendix?
- How Does Mendix Handle Transaction Management?
- What Databases Does Mendix Support?
Persistable objects are stored in a database, and Mendix automatically creates tables to store your entities in the database. For every object, one record is inserted in the table. Non-persistable entities only live in memory for the duration of a user session.
For every entity, you can define the attributes and what type of data the attributes should hold. You can also define security rules, who can see what data, and validation rules. A validation rule specifies what values are allowed for an attribute.
When you start or redeploy your application, Mendix automatically creates database tables to store your data. When you redeploy, all of your app’s tables are automatically changed as required, and data is migrated to the new table structures.
Persistable objects are stored in a database, so you can use your data across sessions and across users. However, because non-persistable entities only live in memory for the duration of a user session, such entities cannot be shared between users or across user sessions.
Non-persistable entities are mostly used for calculations where you do not want to store all the intermediate results, or for temporarily storing data fetched from external systems through different integration means.
Mendix object-relational mapping (ORM) handles all aspects of your database management, from your modeled data needs to technical storage and retrieval with most popular relational database systems. The main goal of Mendix ORM is to remove the need for users to think about technical database aspects, like how to create and modify tables or access and update data.
Indexes are lists of attributes for which a database index is created on the underlying database table of the entity. Indexes improve the speed of retrieving objects if the indexed attributes are used in a search field, in the XPath constraint of a data or template grid, or in an XPath query.
Indexes are added using the entity properties menu inside Mendix Studio and Mendix Studio Pro. Multiple indexes can be added to one entity.
Using a stored procedure in Mendix depends on where your data resides.
If you want to use a stored procedure in the database of your Mendix application, you can use the Mendix Java API. For more information, see How to Use the Java API in the Mendix Studio Pro How-to’s. And for details on executing SQL statements on your Mendix app database using JDBC, see DataStorage executeWithConnection.
If you are using an external database, you can use the Database Connector add-on available in the Mendix Marketplace.
Calling stored procedures is mostly relevant if you are building on top of an existing legacy database. In this area, there are a lot of Oracle relational database management systems (RDBMSs). The Oracle Connector (Beta) available in the Mendix Marketplace provides support for features often seen in legacy Oracle databases, such as table APIs built with PL/SQL stored procedures and packages, ref cursors, and user-defined types.
Every request to the Mendix Runtime automatically starts a new transaction. Upon successful completion of the request, the transaction is committed with all related data. In case of an error, all the data changes are rolled back by default. You have the option to provide custom error handling logic to change this default behavior.
In the following microflow, a custom error handler is defined. When the Change activity fails, any changes it made to the database are rolled back. The error handler defines what you want to do with the transaction: you can roll back everything that happened in the microflow, or you can compensate for the problem and continue. In this example, a log message is generated, after which the microflow ends in an error. The calling microflow can then decide how to handle this.
A Mendix application can by default be deployed to a number of different database servers. As long as you do not include any database-specific code, you can switch database vendors at any moment.
The Mendix Platform supports the database servers listed in the Databases section of System Requirements.