A lot of times when working with non persistable entities they are set up in such a way that only one object of this enity can exist at a time (per session ofcourse).
If you want to retrieve this non persitable object from a persistable one the result will always be a list since 1-1 association are impossible. This means you have to to do a combination of a retrieve and list operation every time.
Thanks for clarifying your use case Ronald, I can get behind that, since I recognize that issue as well.
I suppose you're right Ronald!
Cheers
This is more a case to make possible one on one relations between persistent and non-persistent. Because I know what you mean but should be solved by making this reference possible.
Regards,
Ronald
I’m working a lot with non persitable entities lately and as a rule these have to have *-1 associations with persitable entities.
A lot of times we're only making a single object for the non persitable entity in which case I know only one exists. However when I want to retrieve it from the persitable entity this always results in a list because of the association type, even though I know only one object exists.
I can imagine this being useful when you don't care which object you retrieve, you just need one of them (either because you want to check if the retrieve is empty, or because it's a one-to-many association that can only have one result in this case, etc.)
I might be understanding this wrong, but wouldn't you also run into the issue that retrieve by association looks into the cache/memory first and only database if it's not in memory? Therefore, what might be first in memory could be different from what's first in database and like Rom says, there's no ordering on the retrieved list in the first place.
Why would you want this? How would you know which object you end up with, since Mendix does not guarantee an ordering on the retrieved list.