Refresh query results always to ObjectManager

I have several object managers but one includes more statistic data and it can not be recreated to allow new queries with refreshed data.So I would need object manager to refresh data also when it is already persistent managed.

I was searching for 
And there in:
procedure TObjectManager.GetUniqueInstances(Objects, TempList, ProcessedObjs:
  TList<TObject>; ADoRefresh: boolean);

I tried to change query result refresh as I needed by making following change:
             if ((ProcessedObjs = nil) or not ProcessedObjs.Contains(Aux)) then //ADoRefresh removed
              if Assigned(ProcessedObjs) then //If added

First test looks like it is working and refreshing database query results always, but I don't know if there might be some side effects.

Is there any other way to do this (I would not like to make source changes)? Could there be also criteria where is additional ADoRefresh-parameter?

Hello, I'm not sure what you are trying to accomplish here. Why can't you use Refresh method to refresh existing object(s), or Clear the manager and perform the query again?

I can not use refresh for every object. It would be too slow. 

I would like to perform only one database SELECT-statemet and get all objects refreshed to my current object manager without clearing (losing other objects) it. 

Well, there are no plans to do that. Is there any reason why you would want that?

Well, Yes Wagner.

In the matter of fact it is not even clear to me why object manager should discard database data. Now it performs SELECT-statement, retrieves up-to-date objects and then discards these objects just because there is managed object with same id. It forces application to perform additional operations leading unnecessary communication, database-load and end-user interface slowness.
I would like to ask, why application should use old data instead of current which is already there?

Because TObjectManager is stateful and working with objects. Your data are your objects, not your underlying database. You might have in-memory modifications of that object and it's the instances of those objects that matter. Nevertheless, you can always clear the manager or perform the query in another manager to get new object instances from the database.

Yes I understand that I can easily use another object manager to retrieved up-to-date information from database. But I have other objects preloaded already to my main object manager. New clean manager don't have these and application needs these referenced objects also.

I might have in-memory modifications, but I think it should be my applications responsibility to handle these. Or just if there could be possibility to give optional doRefresh-parameter to criteria then application could decide if wants to retrieve managed objects or refreshed ones. 

Just to let application to control if needs up-to-date information.


Maybe you could rethink the way you are dealing with the objects? This "main manager" approach?

I could but I'm looking for performance issues. 

I have lazy loaded proxy references and I don't want to load these every time again and again with new clean object manager. Just accepting already retrieved object to object manager would be most efficient if you thing about communication resources. And when there is some latency you need to consider these. 

ON the contrary, if you reload the object from the database, the proxies will be reset and marked to be loaded again. If you keep the objects in memory,  the loaded proxies will stay as they are. 

What I mean is not about performance, but about the way you deal with objects instances, the fact that you have to keep references. Usually, speaking very generally, you wouldn't want to keep your objects alive for too long. You load them, deal with, and discard them as soon as you're done. 

Doesn't TCascadeType.Refresh control if proxies should be reloaded in that case or not?

The point would be just to left criteria query to use something like this :
//if refresh, then first copy all property values
Explorer.CopyFieldValues(Objects, Aux);

For the end user if they are complaining about application speed I can not explain about theory of  objects lifetime management. Aurelius is great but I think for many of us it would be easier to understand if criteria-query would be able to use retrieved properties. There have been some another posts here in forum also.

Sorry If I don'd understand something.. but just changing two lines in Aurelius.Engine.ObjectManager.pas I was able to get up-to-date object properties with criteria-query for objects that already where managed. 

We cannot break backward compatibility. So we will have to add an option. And test extensively, and check and think if it will behave strangely in some situation. So it's not that simple to make it official, even though of course you are allowed to change the source code yourself and use it, that's no problem.

So that's why I'm a little bit refraining of doing those changes - it comes with some responsibility. Since we didn't receive requests about that since Aurelius was released 3 years ago, I tend to think there are other options to use it. I'm open to change it, but I need to understand more why you need it and why most (all?) people using Aurelius so far didn't need it (or didn't bother to ask). 

If there are other users willing to comment, I'd like to hear other opinions. You can also add that feature request to be voted by other users. And if you feel like it, you can also explain better to me why you need that feature, since I couldn't understand your architecture well enough to understand why can't you retrieve new object instances.
Yes I know it will be much more than just writing some rows of code. 

Same issues was here in the formus just few posts earlier:

If the solution would be to rethink object manager strateqy then I cant see it as efficient  life time management. I would like to keep my statistic data managed and then query associated live data from MSSQL-database. Now after criteria query I have ObjectManager where some objects are up-to-date and some not.

You will probably soon release some new products supporting local database and synchronizing to server. I'm keen to see what's coming.

I created new request (wondering it haven't been created by anyone yet) as:
1978: Aurelius query refreshing managed objects automatically 
Now database query (by criteria) ignores objects which are already managed by ObjectManager. I requesting possibility to automatically refresh also managed objects. (copy field properties).
That would let easier life time management without recreating new ObjectManagers (and reloading again associated objects) or very slow object-by-object refreshing. 


Keeping an object manager alive for too long and with too many objects might (might) be asking for trouble. That's why I'm saying that maybe it's better to think better about the architecture. An object manager is a dataset. While it's possible, we all know now that keeping a dataset open for the whole application lifetime is not very good practice. An object manager is usually used for quick, atomic operations, in "worst" cases, for visual stuff, while the form is open. 

>> You will probably soon release some new products supporting local database and synchronizing to server. I'm keen to see what's coming.<<

Yes. We plan to do so. Was that just an unrelated question, or is there and relation with the subject?

Mostly unrelated. I just mentioned that I have been considering to rethink application architecture after seeing what kind of new products or features TMS will be providing. 

Hello all.

My five cents: I need to refresh-on-query managed objects too. 
Environment: User1 on Machine1 create a document with Status1. User2 on Machine2 do some action, and Status change to Status2. User1 refresh AureliusDataset event X seconds, but he can't see changes in objects, because changes was made another user in DB, not through User1's Manager.
And yes, I can't do clear before refetch. 

Why you can't do clear before refetch? If you are using TAureliusDataset, things are even worse, because the dataset keeps data in internal buffers. In every dataset, to refresh data, you need to close/open the dataset (TDataset.Refresh just does it internally)