(Hope it’s clear).
Everything is set to “autoload”, so when we retrieve the Absence items via a GET, we should have a list of “Absence” items, each one has a “enterprise” and a “user”, and each “user” has an “enterprise” (which may be different from the Absence Enterprise, but could be the same).
What’s wrong is that the “Enterprise” in the user is not loaded. Instead, we get something like this:
This is not a bug. It seems that you’re having the same object somewhere in relation (maybe in a cyclic one), so instead of duplicating it we put these “__originSubId” and “__subId” properties in order to indicate that.
This is done to send less data over the network - but the SDKs automatically handle these properties and transform them into objects.
These IDs appear when you already have the same object in the response. So you may just look it up there by its ID.
This is not really related to an object size, it is rather a way to reduce the number of duplication in the response and a way to handle cyclic relations (when an object is related to itself either directly or through several other relations).
@mark-piller I’m seeing this __originSubID values all in my JSON data. this is not a feature, this is a bug. My expectation is that my data show up exactly as I modeled it. Anything else is just corrupted data. I’m noticing it also when fetching data from Rest Console. This has been an issue also noted here. Dealing with __objectRef, __arrayRef, __originSubID