Ed Leafe wrote: > On Feb 28, 2007, at 8:52 AM, Uwe Grauer wrote: > >> It is a bug. >> If dabo would first try to delete the child and after that the parent, >> the database ref constraints wouldn't be violated. >
Isn't the above the way it should work? > It is not a bug. > > If you set up your RI correctly, there would be no problem. > My RI is set up correctly. These are just constraints to make sure the RI isn't violated. If i had it set up so that the database does deletes, you would be right, that i should tell dabo to ignore RI. You could have said that it is not the way it is implemented in dabo and that i have to do the deletes myself because dabo wouldn't handle it correctly otherwise. What you said sounded if you would tell me that what i said was wrong because: I said: "Can't work, as i do have referential integrity in my database." You said: "That's not a bug. It's supposed to work this way. Referential integrity can be either handled in the database, or at the bizobj level. Not both." Why not both? It would work if dabo would delete the childs first. > Uwe, perhaps this is a language thing, but this is terribly > insulting. I'm hoping that you don't mean to sound that way. I've > been working with data for a long, long time, and am familiar with > basic stuff like RI. Terribly insulting? Sorry, that wasn't meant this way. I thought you meant RI is supposed to work that way, but with RI constraints it is supposed to delete the child records first. That's why i included a reference to the RI doc. > > Dabo allows databases that don't have native RI to create their RI > at the bizobj level. If you have RI built into the database, then you > shouldn't be trying to duplicate it at the bizobj level. > Why not? Just because my db has RI constraints doesn't mean that dabo does it the right way, or it is wrong to have RI constraints in the db. > When this code was first created, the majority of users were using > MySQL ISAM tables, which do not support RI, so the defaults were set > to what made the most sense for them. Perhaps, given the much greater > number of backends out there that we support that can handle RI > themselves, we should change the default to turning RI in the bizobj > off. Anyone who relies on this being on will have to explicitly set > it on, or their code will break. Thoughts? > Sorry again if my reference to the RI doc sounded offending to you. I don't think that turning RI off in dabo would be a good thing, as RI constraints in the database mostly try to prevent RI violations. Another thing is, if the db itself does the deletes. But this isn't the case mostly. In fact, in big databases it would be wrong because the db doesn't know all the dependencies. We can turn RI off in dabo if we need to. Would you please try to not delete too much of older messages, because i very often have to go back to the original posts to understand your answers. Can we agree that dabo is wrong to delete the parent first and that it should be fixed to correctly handle FK constraints? Uwe _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
