ObjectTrackingEnabled in LinqConnect 4.0

[asaake]

Is there a change in handling ObjectTrackingEnabled?

My entities have a version column and so I read them with ObjectTrackingEnabled = false. I expected (and think I verified) the context to store no references about read entities (like projecting into anonymous classes).

On submit I create a new context, "clone" the entities and use them with this new context, which is destroyed after sending to database.

Now, in LinqConnect 4.0, when I try to read an entity again from the database, while the read context still exists, I get not the database values, but the actual values. I've tried setting EntityCacheMode to both values, with same result.

Only using a new context gives me the stored results.

Is my expectation wrong, that reading with ObjectTrackingEnabled = false is a "read and forget" mode? Unfortunately I cannot verify it by myself without a rollback to the last version of LinqConnect, so my question, how it is meant to work.

[StanislavK]

The ObjectTrackingEnabled property specifies whether the context tracks the changes in the entity objects; i.e., whether it should subsctibe for the PropertyChanging event, create the entity copy storing the initial values etc. Regardless of the ObjectTrackingEnabled value, the context caches loaded entities.

The EntityCacheMode property affects the way the entities are stored in the cache: the context keeps either strong or weak references to them. By default, the WeakReference mode is used, allowing you to dispose your entity objects while the context is alive.

Please specify if anything is unclear.

Also, could you please describe the purpose of disabling entity caching in more details?

[asaake]

My intention was to have no entity cache at all. I would like to use the context as an OracleConnection with Linq.

When I read data, I want to get fresh data from the database in every case, because data may be changed by stored procedures outside LinqConnect, too.

I'm aware that I can achieve that by disposing the context after every query. But if I understand the docs right, the context stays alive as long as the entities are alive, so I would have to project the entities and dispose the entities, too, to get really rid of the context.

Because of this scenario I disabled ObjectTracking and thought to have a solution.

Could the new WeakReferenceMode help me in this ? How could I direct the context with this option to read fresh data?

[MariiaI]

We will consider implementing the possibility of disabling the entity cache, and inform you about the results.

The DataContext object doesn't depend on its entities, so it could be disposed at any time.
As for the question about the WeakReference mode, this mode allows you to dispose entities while working with context. Entities will be removed when there is no need in them. However, this method does not guarantee that entities will be re-materialized after each query. WeakReference mode is a default mode, so you don't need to do anything to use it.

You can also use the Refresh() method to retrieve the actual data from the database. This method updates specific objects in the object context with data from the data source.
For more information about the Refresh() method please refer to:
http://www.devart.com/linqconnect/docs/ ... fresh.html
http://msdn.microsoft.com/en-us/library ... hmode.aspx

[MariiaI]

The possibility to disable query cache via the DataContext's 'EntityCachingMode' property is added.
New build of LinqConnect 4.2.247 is available for download now!
It can be downloaded from http://www.devart.com/linqconnect/download.html (trial version) or from Registered Users' Area (for users with active subscription only).
For more information, please refer to http://forums.devart.com/viewtopic.php?f=31&t=27137.