I am not advocating the loss of data integrity. The reason machine A gets an error is because the category couldn't be removed -- because there was an already existing, non-deleted product with a foreign key into the category to be removed.
Thus, after A fails, the category is still present in the DB -- there is NO loss of data integrity. (And given the use of transactions in DataContext.SubmitChanges(), the products that machine A tried to remove would also still be present, as the transaction itself would have been aborted.) Again, no loss of data integrity. The question isn't so much do the DBAs know what they're doing, but do the developers know what they're doing? Very often, the answer is, sadly, no, so we need to opt for safety. In this case it is clearly safer to abort the delete request when there are still outstanding references to the table being removed, so that is clearly what should be done. - Jon On Wed, 2009-05-20 at 18:04 +0200, Giacomo Tesio wrote: > 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 -~----------~----~----~----~------~----~------~--~---
