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 :pJust 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 -~----------~----~----~----~------~----~------~--~---
