Commit Object(s)

Introduction

The Commit object(s) activity works on one or more objects. For persistable entities, committing an object writes it to 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 cannot be committed. To store changed values of external objects, use the Send External Object activity.

Properties

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

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:

• Action
• Common

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, or right-clicking the activity and selecting Properties.

Object or List

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

With Events

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

Default: Yes

Events in Nanoflows

Nanoflows do not have this property.

If the Commit object(s) activity 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) activity is used in an offline app, the changes are committed to the offline database, and event handlers are run when the offline app synchronizes.

Refresh in Client

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

Default: No

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.

Microflow is Called in an Offline or Native App

When inside a microflow that is called from an offline or native 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 Offline-First Data.

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.

Common Section

How Commits Work

In understanding commits, it is important to remember that each persistable object has two states:

1. The state in the database where the values are shared with every other user of the app. This is the state you get when you retrieve an object which is not already in the app's memory.
2. The state in memory where values changed by the app can be seen.

Non-persistable entities behave like the in-memory version of a persistable object.

Committing Objects

When you commit an object which is in memory, changes to the values are saved in the database. Once it is committed, you cannot roll back to the previous values of the object using the Rollback object activity of a microflow.

However, a Mendix commit is not the same as a database (SQL) COMMIT. When you use a Commit object(s) activity, Mendix actually performs an INSERT or UPDATE on the database. For an object of a persistable entity, the database COMMIT is not performed until the microflow and any microflows from which it is called, complete. This means that, although a retrieve from the database by the end-user's app will see the updated version of the object, the updated object will not be seen globally by other end-users until the microflows end.

Another consequence of this distinction is that, in contrast to an explicit Rollback object call, which rolls back to the last Mendix commit, errors in a microflow can initiate a database rollback. If a microflow activity errors and has Error handling set to Rollback or Custom with rollback, the value of the object in the database is rolled back to the value it had at the last savepoint. The object in memory will, however, keep any changes to the values. See Error Handling in Microflows for more information.

What Gets Committed

When you work on an object in memory, Mendix records whether the object has been changed. When you perform a Commit object(s) activity, changes to the current values are written to the database and Mendix marks the object as unchanged in memory. This has a couple of consequences that you might not expect:

• If you commit an object and the transaction is then rolled back due to an error, committing the object again will not write the latest version to the database. You can understand this as the following sequence (see Error Handling in Microflows for a more detailed discussion of how rollbacks work during error handling):

  1. Your microflow starts and creates a savepoint.

  2. You change your object in memory – it is marked as changed.

  3. You perform a Commit object(s) activity which sends the changes to the database – the object in memory is marked as unchanged.

  4. An error occurs in an activity after the Commit object(s) activity has successfully sent changes to the database – the microflow ends and data in the database is rolled back to the savepoint.

  5. You perform a Commit object(s) on the object again, but the changes are not written to the database because:

     • The object in memory still has the updated values but the attributes were marked as unchanged after your previous commit
     • The Commit object(s) activity does not see the changed marker and so does not recognize that your object in memory has changes which need to be written.

  If you want to keep the changes in the version which is in memory, you will have to work around this behavior by changing the attributes of the object again.

• Deleting an object and then committing it has different outcomes depending on whether the object has already been committed or not:

  • If the object has already been committed, the delete will remove the object from the database, and the subsequent commit will have no effect.
  • If the object in memory is new (that is, it has not been committed before you delete it), the delete will do nothing. However, the subsequent commit will write the object to the database. Therefore, this sequence of actions (a delete followed by a commit) may lead to unexpected results if the object has not been committed before.

Committing Non-Persistable Entities

Mendix mimics this behavior for non-persistable entities. This means that performing a commit on a non-persistable entity means that you cannot use a Rollback object activity to go back to the previous values.

Autocommit and Associated Objects

When an object in memory is committed through a default Save button, a commit activity, or web services, it always triggers the commit events. 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 is 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 is 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 commits, the following occurs:

• 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 are kept
    Before and after events are not executed for autocommitted objects.
• Database:
  • There is an insert or update query executed both for explicitly committed objects and autocommitted objects
  • Depending on the object state, the Mendix Runtime does an insert for objects with the state Instantiated and an update for all other states
• Result:
  • An object with the state Instantiated is inserted into the database, and an object with any other state is updated