var lUser := FManager.Find<TUser>.Where(Linq[Dic.User.userName.PropName] = aUserName).UniqueResult;
if lUser = nil then
Raise ESiteModel.Create('Site not found for Username ' + aUserName);
Result := lUser.SiteId;
In the above code, it all seems to work ok, but if I uncomment the Flush, then the contents of result are cleared. I'm curious if this is the correct wat to keep an object after the manager has been disposed and the connection closed. If it's not the correct way, then is there a way to do it or do I need to manually copy the object to one thats not in the object manager ?
Manager.Evict( Object )
Is the right way to do it, indeed. Is SiteId an associated object ?
From your code snipet you do not need no call Flush since you're not doing any updates on lUser (or any associated objects).
You could also use:
Manager.OnwsObjects := False
After creating the manager but this would make entire lUser object not owned by the manager.
Thanks for the confirmation. In relation to the associated object, if my understanding of an associated object is correct (and it may not be) then the answer would be yes as the eventual result comes from the Site table which was a foreign key on the User table. I'm not interested in the User table (so perhaps a better approach would be to load the Site table rather than starting from the User table).
The lUser variable and any other properties from other tables apart from Site are not required.
I hope this makes sense.
I definitely don't want (or need) to keep all objects contained in the manager.
Evict is the correct way. But as @Farias_Anderson said, you shouldn't call Flush.
Also, if you are removing the object from the manager, then you should not have a reference to a transient object in a managed object.
lUser.SiteId still references the evicted object, that is not automatically cleared by the manager when you do evict). So you are in a really weird situation when you call
Flush, that's why you should have a good reason to do so - which doesn't seem to be the case.