Understanding caching of entitiy

0
I thought when you retrieve an entity by association you always get the object with his values that are in cache on the moment of the retrieve with all changes that previous are applied on his attributes?But now I got a situation where I retrieve the same object (checked the id) and it looks like the values are not the same as previous in the same action? Sso I wonder how that works.I have a entity (call it: ENT_1) with 2 associations: ASS_ENT_2 and ASS_ENT_3.I call a microflow where I retrieve ENT_1 by the Association ASS_ENT_2 (association to another Entity)In this microflow I change some attributes of ENT_1After those changes I make a (sub)call to another microflow (input parameter is a object of ENT_3 because it's an existing microflow and i do not want to change that one) and in that microflow there is a retrieve by association ASS_ENT_3.When I look to the id of the retrieved object it is the same as in my previous retrieve with ASS_ENT_2 but now those previously changed attributes again have their original values (so the ones from before my changes?)Is this expected behaviour?I thought that every retrieve by association of the same object will always return that object with all his latest changes from your current session (so caching?). Or I'm I completely wrong here?So can there live multiple versions of the same object in memory, is this dependant on the association?Not sure if my question is clear ...
asked
2 answers
2

In short: Yes, this is expected behavior. Multiple versions of the same object can exist in memory.


Why it happens:

  • Isolation: Your changes in the first microflow are "uncommitted."
  • Retrieve Logic: While "Retrieve by Association" often uses the cache, if Mendix determines the path via ASS_ENT_3 is not yet in the current local "state" of the sub-microflow, it may pull a fresh copy from the database, which doesn't have your changes.

The Fix:

  1. Commit: Commit ENT_1 before calling the sub-microflow.
  2. Pass as Parameter: Pass the modified ENT_1 directly to the sub-microflow to ensure you are working on the same memory instance.
answered
1

Hello Didier,


This seems in fact to be expected behaviour,


It is possible to have "different instances" of the same object in memory, with the same ID, because you change an object and never commit it, later you retrieve it through a different association this will still point to an older in memory instance (without the changes you made to the first intance you retrieved and changed). In Mendix you can't guarantee a single in memory intance of an object.


So when you retrieve this object (ENT_1) through association A you get instance 1#
Then you retrieve same object (ENT_1) through association B you get instance 2#

Both with the same ID.


I can't fully grasp the logic here from your example, but I recommend with this information you maybe commit the changes and do a database retrieve so you are sure to use always the same instance of the ENT_1 and test this logic.

Also another important concept it may be usefull to know about the by association retrieves, when an object is retrieved by association but it is not in cache Mendix will retrieve it from the database as described in the documentation here:

Mendix Academy - 3.1 Database vs. Association Retrieve - Data in Microflows - Win at Working with Data


"Data Retrieved by Association

When retrieving data by association, the platform will first determine whether the requested objects are already available in the memory (1-2), in the so-called object cache. If the data is not available, the platform will retrieve the object from the database (3-4). You can use the debugging tools in Studio Pro to verify whether an object is retrieved from the memory or the database."


Hope this helps, if you have any further question or want to expose some screenshots with the example please feel free.


answered