Again on this topic: reading more deeply the r1073 changelog I saw
* DbLinq/Data/Linq/DataContext.cs:
- One IEntityTracker isn't enough, due to Scenario C, so create two:
CurrentTransactionEntities are all entities submitted since the
previous SubmitChanges() request, while AllTrackedEntities are,
well, *all* tracked entities. During SubmitChanges() entities are
moved from CurrentTransactionEntities into AllTrackedEntities, as
appropriate. This allows Scenario C to work as expected.
This reply to half of my previous question about the
CurrentTransactionEntities property meaning.
Just a little question about the Scenario C: why can't we rely on the db
foreign key triggers on delete?
Or we do and use the CurrentTransactionEntities to make some magic I haven't
focused?
Giacomo
On Wed, May 20, 2009 at 9:35 AM, Giacomo Tesio <[email protected]> wrote:
> Hi, I've noticed a strange behaviour in the
> ReadTest.C16_GettingProperty_DeferredLoadingEnabled2False()
> It pass if run alone, but fail if run in tandem with the others...
>
>
> I've also noticed that it has been modified the EntityTracker property in
> the DataContext class to a more proper name "CurrentTransactionEntities".
> I suppose this was related to the recent Jon works about the EntitySet.
>
>
> I'm not sure this is related to the test strange behaviour, but it could be
> (since setting DeferredLoadingEnabled cause CurrentTransactionEntities to be
> a DisabledEntityTracker and some DataContext behaviour changes)
>
>
> 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
-~----------~----~----~----~------~----~------~--~---
