I do'nt understand why you create global DataContext. If I understood properly good design practice is to have only short-living Datacontext's, even in WinForms applications. DataContext is created for single unit of work and must disposed after work unit (ie. saving and invoice) is completed.
Initially I tried to use Pascal object tracking + global Datacontext to implement globale cache for Winforms application but failed since there is no way to signal to Datacontext that some entity was changed. I created my own cache implementation based on wrapper methods which create temporary datacontext. Nowadays I moved from Winforms to Silverlight. In this case I create DbLinq Datacontext in every web service call and dispose it in this call. Andrus. ----- Original Message ----- From: Giacomo Tesio To: [email protected] Sent: Friday, April 03, 2009 12:13 PM Subject: Re: ReadOnly DataContext (aka ObjectTrackingEnabled and DeferredLoadingEnabled not implemented) This workaround could not be used in our environment. I was planning to create a readonly DataContext which stay alive. When data will require to be saved a new copy of entities is sent to a service. Other (read/write) DataContext will be created when required, but the "single" readonly one should not be tracking object. Giacomo On Fri, Apr 3, 2009 at 11:04 AM, Andrus <[email protected]> wrote: I "fixed" this in the following way: I create new DataContext for every query which requires fresh data. Andrus. ----- Original Message ----- From: Giacomo Tesio To: [email protected] Sent: Friday, April 03, 2009 11:58 AM Subject: Re: ReadOnly DataContext (aka ObjectTrackingEnabled and DeferredLoadingEnabled not implemented) Well, so by decison the DbLinq DataContext will always behave differently from the Microsoft one? http://msdn.microsoft.com/en-us/library/system.data.linq.datacontext.objecttrackingenabled.aspx in the remarks report that "Setting this property (ObjectTrackingEnabled) to false improves performance at retrieval time, because there are fewer items to track." I'm not sure about what items will be tracked when I actually say that they should not be tracked. But, performance a part, I'd like to be able to really disable the tracking. Also becouse I could actually prefer to not get the recently loaded customer since it could be changed in the db. Giacomo On Fri, Apr 3, 2009 at 9:58 AM, Pascal Craponne <[email protected]> wrote: The identity tracking must not be stopped: within the same DataContext, the same request done twice will return twice the same object. The things to change are just the SubmitChange() and a few others. On Fri, Apr 3, 2009 at 09:06, Giacomo Tesio <[email protected]> wrote: I'll search... Actually, what is not so obvious is to really stop the identity tracking. This should produce faster DataContext during selects. DeferredLoading is actually a big miss. We should address it. We MUST document such a missing feature somewhere visible (since the Linq to Sql enable it by default!), or we become like Microsoft which often document only what works as expected (actually I did expect that it was working... fortunally it sould not be a problem for our design...). About the exception, we could throw a NotImplementedException when the user explicitly set true to DeferredLoadingEnabled, while not when he set it to false. We should also throw on each query when deferred loading is enabled (by default it is, according to the documentation), but I'm not sure it's acceptable... Anyway, I think that a list of missing features is every day more urgent! That said, what I should change to disable object tracking when ObjectTrackingEnabled is false? Giacomo On Fri, Apr 3, 2009 at 12:02 AM, Pascal Craponne <[email protected]> wrote: Pong*. Well, apparently the changes are obvious :p Just check the value and throw the exceptions when necessary. Regarding deffered loading, that's probably not as simple. We had threads on it a long time ago, and I suggest you to search in the group archives. * Answering "pong" to a "ping" is probably just a french joke. Sorry. On Thu, Apr 2, 2009 at 23:56, Giacomo Tesio <[email protected]> wrote: Ping! :-D Giacomo On Wed, Apr 1, 2009 at 9:29 AM, Giacomo Tesio <[email protected]> wrote: Ok Here's the relevant documentation and the exceptions thrown. Note that we should also consider the LoadOptions property (and the DataLoadOption class) What shoud be the working plan? bool ObjectTrackingEnabled Instructs the framework to track the original value and object identity for this DataContext. Setting this property to false improves performance at retrieval time, because there are fewer items to track. An exception is thrown: a.. If the property is set to false after a query has been executed. [1] For more information, see the Valid Modes section in DataContext a.. If the property is set to false and SubmitChanges is called. [2] bool DeferredLoadingEnabled Specifies whether to delay-load one-to-many or one-to-one relationships. When false and the code accesses one of these relationships, null is returned if the relationship is one-to-one, and an empty collection is returned if it is one-to-many. The relationships can still be filled by setting the LoadOptions property. Deferred loading requires object tracking. Only the following three modes are valid: a.. ObjectTrackingEnabled = false. DeferredLoadingEnabled is ignored and inferred to be false. This behavior corresponds to a read-only DataContext. b.. ObjectTrackingEnabled = true. DeferredLoadingEnabled = false. This situation corresponds to a DataContext that allows users to load an object graph by using LoadWith directives, but it does not enable deferred loading. c.. Both are set to true. This is the default. The flags may not be changed after a query has been executed. Any change after the execution of the first query that uses that DataContext throws an exception. [3] Exceptions thrown: [1] System.InvalidOperationException was unhandled Message="Data context options cannot be modified after results have been returned from a query." Source="System.Data.Linq" StackTrace: at System.Data.Linq.DataContext.set_ObjectTrackingEnabled(Boolean value) at DbLinq.Mssql.Example.Program.Main(String[] args) in C:\Projects\Labs\Linq\DbLinq\examples\DbLinq.Tests\Program.cs:line 109 at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args) at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args) at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly() at System.Threading.ThreadHelper.ThreadStart_Context(Object state) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Threading.ThreadHelper.ThreadStart() InnerException: _____________ [2] System.InvalidOperationException was unhandled Message="Object tracking is not enabled for the current data context instance." Source="System.Data.Linq" StackTrace: at System.Data.Linq.DataContext.VerifyTrackingEnabled() at System.Data.Linq.DataContext.SubmitChanges(ConflictMode failureMode) at System.Data.Linq.DataContext.SubmitChanges() at DbLinq.Mssql.Example.Program.Main(String[] args) in C:\Projects\Labs\Linq\DbLinq\examples\DbLinq.Tests\Program.cs:line 109 at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args) at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args) at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly() at System.Threading.ThreadHelper.ThreadStart_Context(Object state) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Threading.ThreadHelper.ThreadStart() InnerException: _____________ [3] System.InvalidOperationException was unhandled Message="Data context options cannot be modified after results have been returned from a query." Source="System.Data.Linq" StackTrace: at System.Data.Linq.DataContext.set_DeferredLoadingEnabled(Boolean value) at DbLinq.Mssql.Example.Program.Main(String[] args) in C:\Projects\Labs\Linq\DbLinq\examples\DbLinq.Tests\Program.cs:line 109 at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args) at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args) at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly() at System.Threading.ThreadHelper.ThreadStart_Context(Object state) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Threading.ThreadHelper.ThreadStart() InnerException: _____________ On Tue, Mar 31, 2009 at 10:42 AM, Pascal Craponne <[email protected]> wrote: Well, I suggest that you list all effects of such parameter (exceptions thrown when specific methods are called), and then we'll see how to implement them. Pascal. jabber/gtalk: [email protected] msn: [email protected] On Tue, Mar 31, 2009 at 10:37, Giacomo Tesio <[email protected]> wrote: Hello everybody! I've figured now that we could need a readonly DataContext for security reasons. In http://msdn.microsoft.com/en-us/library/system.data.linq.datacontext.deferredloadingenabled.aspx it is said that that would be possible, by setting DataContext.ObjectTrackingEnabled = false. Actually those two proprerty required to get such a behaviour throws NotImplementedException. I could try to implement them, at least to get the readonly behaviour (which even if not trivial, should be possible in a reasonable time). Can someone get me an overview of the required modifications and point me to the place to start? Giacomo --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DbLinq" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/dblinq?hl=en -~----------~----~----~----~------~----~------~--~---
