Date: Sun, 19 Apr 1998 22:46:14 +0100 From: Karl Pielorz <kpielorz@tdx.co.uk> To: Terry Lambert <tlambert@primenet.com> Cc: allen campbell <allenc@verinet.com>, hackers@FreeBSD.ORG Subject: Re: (was Discussion : Using DHCP) - Now 'Config Databases' Message-ID: <353A70A6.E90B3645@tdx.co.uk> References: <199804192133.OAA14057@usr08.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Two things... 1. The subject line on this message is the worst I've seen in a long time - Will whoever replies next tidy it up properly (like I didn't! :-) 2. This has been cross-posted to hackers & config... I've only posted it to hackers - as looking back that's where most the messages went... I'm all to willing to move to Config if that's where it's / were meant to be! <g> Someone else wrote: > > How do you address an assertion which says dependency on a database > > reduces robustness because of, for instance, database corruption? > > Do you disregard the assertion based on evolutionary necessity > > ('bite the bullet') or do you dispute that there is any significant > > compromise at all? Terry Lambert wrote: > I dispute that there is a significant compromise. > > There *is* a potential compromise. Opponents of using a database > design point to partial corruption equalling partial recoverability > in the flat file. > > I would point out to this position that the flat files use the > underlying file system, which has the same semantics as those > that have been proposed for the user space code. > > [snip - holy cow, what a lot to snip!] For my $.02 worth: I used to use an application on SCO (I forget the name now) that used to hold _all_ it's config in a database... The database was like the 'dreaded registry', i.e. proprietry format etc. - But what it did have (that really saved it's self!) was a number of utilities for exporting the database out in text format, and for important text files into the database - The database design was also pretty good as well - i.e. if it did get corrupt (which it only did once) - the 'dump' routines would get as far as the corruption - perhaps screw up a couple of records - and then keep going with the others... Thus you'd get a couple of 'dodgy' records in your text dump which you could edit by hand, then nuke the config database - and re-import the text file once it was cleaned up... It would be nice to see a config database done 'the propper way', i.e. not liable to application corruption etc. - perhaps even with 'descriptions' for all the records it holds... ;-) ho hum... Another can of worms just opens... Regards, Karl Pielorz To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?353A70A6.E90B3645>