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 <[email protected]> > *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.aspxin > 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<http://msdn.microsoft.com/en-us/library/system.data.linq.dataloadoptions.aspx> >>>>>> ) >>>>>> >>>>>> 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: >>>>>> >>>>>> - If the property is set to false after a query has been executed. >>>>>> [1] >>>>>> For more information, see the Valid Modes section in >>>>>> DataContext<http://msdn.microsoft.com/en-us/library/system.data.linq.datacontext.aspx> >>>>>> >>>>>> >>>>>> - >>>>>> >>>>>> If the property is set to false and >>>>>> SubmitChanges<http://msdn.microsoft.com/en-us/library/system.data.linq.datacontext.submitchanges.aspx>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<http://msdn.microsoft.com/en-us/library/system.data.linq.datacontext.loadoptions.aspx>property. >>>>>> >>>>>> Deferred loading requires object tracking. Only the following three >>>>>> modes are valid: >>>>>> >>>>>> - >>>>>> >>>>>> >>>>>> ObjectTrackingEnabled<http://msdn.microsoft.com/en-us/library/system.data.linq.datacontext.objecttrackingenabled.aspx>= >>>>>> false. DeferredLoadingEnabled is ignored and inferred to be false. >>>>>> This behavior corresponds to a read-only >>>>>> DataContext<http://msdn.microsoft.com/en-us/library/system.data.linq.datacontext.aspx> >>>>>> . >>>>>> - >>>>>> >>>>>> >>>>>> ObjectTrackingEnabled<http://msdn.microsoft.com/en-us/library/system.data.linq.datacontext.objecttrackingenabled.aspx>= >>>>>> true. DeferredLoadingEnabled = false. This situation corresponds >>>>>> to a >>>>>> DataContext<http://msdn.microsoft.com/en-us/library/system.data.linq.datacontext.aspx>that >>>>>> allows users to load an object graph by using >>>>>> >>>>>> LoadWith<http://msdn.microsoft.com/en-us/library/system.data.linq.dataloadoptions.loadwith.aspx>directives, >>>>>> but it does not enable deferred loading. >>>>>> - >>>>>> >>>>>> 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<http://msdn.microsoft.com/en-us/library/system.data.linq.datacontext.aspx>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.aspxit >>>>>>>> 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 -~----------~----~----~----~------~----~------~--~---
