Deep clone : Members to keep all

0
Hello,   I've been working on an application where the client wants to be able to view the whole life history of an object. Since this object can run trough multiple workflows I implemented an index management First iteration as index "A", second as index "B" and so on...   When creating the new index object I used the "Clone object" java action which worked just fine until I realised it also copies the "createdDate" member which is managed by the system and no way to overwrite it   Considering I'm using the createdDate member a lot as a sorting argument, that would conflict with my logic as the createdDate doesn't have the value it's supposed to have (which is supposed to be the date the new indexed object is created)   Looking trough this issue I saw a lot of post with every answer being "use Deep clone java action"   This brings another issue has my object has lots of members and relations   I wondered if there is a way to use Deep clone with a "all member" argument as members to keep since writing then all down would be time consuming and a source of potential error   Thank you for your time.
asked
2 answers
1

Mendix Object Cloning – Technical points for Issue Solving 

  1. Issue with Standard Clone Object Action

    • The standard Clone Object Java action copies all attributes, including system-managed ones like createdDate and modifiedDate.

    • These attributes are read-only in Mendix UI and cannot be overwritten via microflows after cloning.

    • Result: cloned objects retain the original creation timestamp, causing sorting and logic conflicts.

  2. Deep Clone Action Usage

    • The Deep Clone Java action clones the object and its related entities recursively.

    • It requires specifying which attributes and relations to keep explicitly—no option for “clone all” by default.

    • This reduces issues with system attributes since you can exclude them.

  3. Manual Specification Drawbacks

    • For objects with many attributes/relations, listing all members manually is time-consuming and error-prone.

    • Missing members in the Deep Clone config can lead to incomplete clones or bugs.

  4. Possible Workarounds

    • Automate member listing: Use Mendix Model SDK or domain model export to generate a full list of attributes and associations for cloning config.

    • Custom clone logic: Implement a Java action or microflow that programmatically copies all attribute values except system-managed ones and resets the createdDate.

    • Use a custom date attribute (e.g., CustomCreatedDate) to track creation timestamps you control, avoiding reliance on system-managed createdDate.

  5. Resetting createdDate

    • Although createdDate is system-managed, advanced techniques (like Java actions with full domain object access) can reset it.

    • This is not recommended due to side effects and maintainability concerns.

  6. References and Resources

    • Mendix Forum thread on cloning issues:https://community.mendix.com/link/questions-about-clone-object-action/

    • Deep Clone Java action documentation and download:https://marketplace.mendix.com/link/component/276/

    • Mendix Model SDK (for automation): https://docs.mendix.com/howto/developer-tools/mendix-model-sdk

answered
1

The most robust and future-proof solution is to manually copy all attributes and relations in a microflow. This is a pain once, but then you’re done and have full control.

I would recommend trying this. 

answered