It's nice to know that the commit messages are actually useful... :-)
So, the problem I was seeing during the debugging was that even though
the test had:
db.Products.DeleteOnSubmit(prod1);
db.Products.DeleteOnSubmit(prod2);
db.Categories.DeleteOnSubmit(category);
That is, remove the products and then delete the category, it was
instead trying to delete the category first before deleting the
products. (This was because there was only one IEntityTracker instance,
which contained elements in a "first load" ordering, so the category was
first in the list because the category was added before any products.)
Hence the creation of CurrentTrackedEntities and AllTrackedEntities, so
that order-dependent operations (such as the above .DeleteOnSubmit()
calls) will be executed in the right order.
Now, why can't we rely on db foreign key triggers? We can't for two
reasons:
1. Portability. Not all databases support foreign key triggers, such as
SQLite (though you can do some post-processing magic to do this, this
isn't the default behavior. Then again SQLite's foreign key support is
"iffy" to begin with...)
2. Safety. Databases can be used from multiple threads, multiple
processes, multiple machines. So while machine A is trying to delete
these products and category, machine B will be adding products to this
category.
So which is preferable: having the DeleteOnSubmit()/SubmitChanges() call
throw on machine A because the category isn't empty, or having machine B
successfully add a product to the category, only to have it be
implicitly blown away by machine A because of foreign key delete
triggers?
I think having machine A throw makes far more sense here, as it's never
a good idea to silently lose data.
- Jon
On Wed, 2009-05-20 at 11:45 +0200, Giacomo Tesio wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
