Commit Object(s)

Last update: Edit

1 Introduction

The Commit activity works on one or more objects. For persistable entities, committing an object stores it in the database. Committing non-persistable entities stores the current attribute values and association values in memory, this allows a rollback to revert to those values. See also Persistability. External objects can’t be committed. To store changed values of external objects, use the Send External Object activity.

2 Properties

An example of commit object(s) properties is represented in the image below:

commit object(s) properties

There are two sets of properties for this activity, those in the dialog box on the left, and those in the properties pane on the right.

The commit object(s) properties pane consists of the following sections:

3 Action Section

The Action section of the properties pane shows the action associated with this activity.

You can open a dialog box to configure this action by clicking the ellipsis () next to the action.

You can also open the dialog box by double-clicking the activity in the microflow or right-clicking the activity and selecting Properties.

3.1 Object or List

The object or list of objects that you want to commit.

3.2 With Events

Indicates whether or not to execute the commit event handlers of the objects.

Default: Yes

3.2.1 Events in Nanoflows

Nanoflows do not have this property.

If the commit object(s) action is used in an online app, it sends a commit request to the Mendix Runtime and always runs the events.

If the commit object(s) action is used in an offline app, the changes are committed to the offline database, and event handlers are run when the offline app synchronizes.

3.3 Refresh in Client

This setting defines how changes are reflected in the pages presented to the end-user.

Default: No

3.3.1 Microflow is Called from the Client in an Online App

If Refresh in client is set to No, the change is not reflected in the client.

If set to Yes, the object is refreshed across the client, which includes reloading the relevant data sources.

3.3.2 Microflow is Called in an Offline, Native, or Hybrid App

When inside a microflow that is called from an offline, native, or hybrid app, the Refresh in client option is ignored and functions as if it was set to No.

For more information, see the Microflows section of the Offline-First Reference Guide.

3.3.3 Action is in a Nanoflow

When inside a nanoflow, the object is refreshed across the client as if Refresh in client was set to Yes.

4 Common Section

For more information on properties in this section, see Common Properties.

5 How Commits Work

5.1 Committing Objects

When you commit an object, the current value is saved. This means that you cannot rollback to the previous values of the object using the Rollback action of a microflow.

However, a Mendix Commit is not the same as a database Commit. For an object of a persistable entity, the saved value is not committed to the database until the microflow and any microflows from which it is called, completes. This means that errors in a microflow can initiate a rollback. If a microflow action errors and has Error handling set to Rollback or Custom with rollback, the value of the object will be rolled back to the value it had at the start of the microflow. See Error Event for more information.

Mendix mimics this behavior for non-persistable entities. Committing a non persistable entity means you cannot use a Rollback action to go back to the previous values, although rollback error handling in a microflow will roll back to the original values.

5.2 Autocommit and Associated Objects

When an object is committed through a default Save button, a commit activity, or web services, it will always trigger the commit events. The platform will also evaluate all associated objects. To guarantee data consistency, the platform may also autocommit associated objects.

An autocommit is an automatic commit from the platform, which is done to keep the domain model in sync. If your application ends up having autocommitted objects, then you will have a modeling error. Since an association is also a member of an object, the association will be stored in the database as well. This means that if you create an order line inside an order and the order line is the parent of the association, when you commit the order line, the order will be autocommitted.

If you end up with autocommitted objects, it is always because of a modeling error. At some point in time, an association was set to a new object, the associated object was committed, and all of its associations were committed as well to keep all the data consistent.

During commit the the following will occur:

  • Events: For explicitly committed objects all before and after events are executed, and if any before-rollback event returns false, an exception can be thrown
    • If an exception occurs during an event, all the applied changes are reverted with the default error handling behavior
    • Changes made prior to the commit will be kept
  • Database: there is an insert or update query executed both for explicitly committed objects and auto committed objects
    • Depending on the object state, the platform will do an insert for objects with the state Instantiated and an update for all other states
  • Result: an object with the state Instantiated will be inserted into the database, and an object with any other state will be updated