On Aug 11, 2004, at 10:51 PM, Sam Tregar wrote:

You must be blessed.  There's a whole class of data-loss bugs that I
know I reported but neither of us could replicate.  Once we decided
that 1.4.6 was our last upgrade it seemed like a waste of your time to
keep bugging you.  A good example would be stories that can no longer
be edited or published because they've got NULL element__id pointers.
How did they get NULL element__ids?  I have no idea.  I've never been
able to make it happen on my own.  But I know it happens because I've
had to go in and nuke them every so often to get the system publishing
again.

None of Kineticode's customers have reported this problem including PIRT. And there are several hundred thousand documents behind that, excluding PIRT. I guess you didn't report it because you couldn't replicate it. I remember you mentioning it, though.

Similar bugs occur with less frequency in the media and category
systems.  Seemingly for no reason at all an object will lose a
critical ID, often in the morass of the member table.  Generally the
only thing to do is to delete it and ask the user to re-enter the
data.  Sometimes it's possible to intuit the missing ID, but that's
definitely not the average case.

This often isn't possible, because the FK columns are NOT NULL. And again, I've only heard about this from you in email threads like this; no other Kineticode customer has ever reported a problem.

My point wasn't to slander Bricolage, just to provide a case where
transactions didn't do much to protect critical data.  In my
experience they're just a tool which can help in unusual
circumstances.  They're no replacement for careful coding and testing.

Yes, well, transactions are no protection from buggy code, regardless of your database choice. So we're in agreement. But I've found having each Apache request constituting a transaction extremely helpful in minimizing data integrity problems.

Yeah, you got me.  I'm a developer.  I've never even met a DBA that I
would trust to work on my data (but I haven't met many)!  Maybe
someday when I do I'll have to use the database he likes to work on.
Until then, I choose!  Would it make sense to have it any other way?

Yes, it makes sense to become a DBA, to a certain degree.

Okay, no more OT missives from me! I need some sleep.

Regards,

David

Attachment: smime.p7s
Description: S/MIME cryptographic signature



Reply via email to