I do not agree. I prefer to loose data, than to loose data integrity.
In the example you provide, what would be the category of the product after machine A had take an error? People designing a database (usually) know what they do, so if the product->category foreign key is ON DELETE CASCADE we should allow this work. If the DBA had put there a ON DELETE RESTRICT the user would get the error from the DB. (talking in the PostgreSQL dialect, I hope it's clear for all). We could not imply what behaviour is right, nor we can impose one. If SqlLite would benefit from such a behaviour, we should enable the Vendor to implement it (probably by adding some virtual to the DataContext, or implementing some kind of TemplateMethod). Otherwise you would impose an usage that could not fit some need. (actually may be it does not fit our, since our DBA really know what they do and our DBs are delegated to keep data integrity at all. The application code is just responsible for those business ruled constraints which are mutable from customer to customer.) Giacomo On Wed, May 20, 2009 at 3:39 PM, Jonathan Pryor <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
