An entity is what you define in a domain model. It holds the entity’s attributes, validations etc. It holds no id-attribute in Mendix, but it does have a table-field in the postgres-database called <entityname>id. An example is entity System.Language.

An object is an instantiation of an entity. Meaning: a row in your database in the table System.Language. That database-row contains the attributes defined in the domain model, and a field ‘<entityname>id’, created by the database-engine and which you can consider to be an object id, or better: an object’s id. It gets created by the MBS, Mendix Business Server. It is not just an autonumber, instead it is calculated by MBS and complies to several MBS-rules, one of them being: id has to be unique. Check out any Mendix-application database and you will find most of the time, the first 9 characters are the same, so yo think they might identify the entities number. But all of a sudden, at a next object, those first characters change as well, because of some MBS logic.

Important to realize: A row’s ‘object id’ is used in the association-tables that it is part of. These only contain two fields per row, both an object id. For instance table userroles, the association table linking entity User and UserRole.

Now: can importing a database that contains object-id’s that are created elsewhere (not by any MBS) corrupt your Mendix-database? Yes. Should I do it: No, unless you have access to the MBS logic for creating and using the objectids, which most of us don’t. Since you can not be sure that you have created object id’s that the MBS can work with, stop right there.

“But I imported it and found not errors”. Ok: you added a duplicate id. Postgres does not mind about that, so not corrupt. MBS does not mind because it does not actively check if the objectid’s are (still) unique. But, having two objects of entity A, say A1 and A2, if one of your two non-unique objects (say A1) get associated to another object (say B1), having a 1-1 or 1-* relation, then, when having object B1 and retrieving associated objects A over association, you would get both A1 and A2. Just one reason, good enough to not go this path. There are more reasons, but you are likely convinced already (if not, you are heading for disaster).

Realize this: The database that you are importing on postgres-level is a normal relation database. The MBS adds logic only know to Mendix (no secret, but no-one cares). Mendix creates the objectids in a way that they seem fit, and they use it in all their CRUD-operations. So better not mess with them, including inventing your own id’s.

Entity ID refers to the registration ID for each row in your database. Each instance at runtime of this specific registration creates a different Object ID. For example, you can access your personal data from the database of a website (same entity ID) on different devices (each with a different Object ID).

The IDs are unique and managed by Mendix.

example of uploaded master data with custom id