Re: [htmltmpl] Re: eWeek Reviews Bricolage
Brought to you by:
samtregar
From: Sam T. <sa...@tr...> - 2004-08-12 05:51:46
|
On Wed, 11 Aug 2004, David Wheeler wrote: > On Aug 11, 2004, at 9:50 PM, Sam Tregar wrote: > > > How can I be so sure? I've worked with big complex systems running on > > both databases. I've watched Bricolage completely destroy user data > > despite using PostgreSQL's transaction support. > > You did? Why was there never a bug report? I have not seen Bricolage lose > data. 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. 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. 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. > > Experience. Wrestle with a database strewn with triggers, > > constraints, abstract types and functions sometime. You'll be begging > > to be back in the moderate mess of a badly designed MySQL DB. There's > > less there so there's just less to do badly. It may not be an > > emperical fact, but I didn't presented it as such! > > But this is typical of the difference between a software developer and a DBA. > I think that one of the main reasons that MySQL is so popular is that > developers like it, because they don't have to think about DBA issues. 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? -sam |