From owner-freebsd-hackers Sun Apr 19 14:47:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA19958 for freebsd-hackers-outgoing; Sun, 19 Apr 1998 14:47:14 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from caladan.tdx.co.uk (caladan.tdx.co.uk [195.188.177.4]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA19882 for ; Sun, 19 Apr 1998 21:46:53 GMT (envelope-from kpielorz@tdx.co.uk) Received: from tdx.co.uk (lorca-tx.tdx.co.uk [195.188.177.242]) by caladan.tdx.co.uk (8.8.8/8.8.8) with ESMTP id WAA00328; Sun, 19 Apr 1998 22:46:40 +0100 (BST) (envelope-from kpielorz@tdx.co.uk) Message-ID: <353A70A6.E90B3645@tdx.co.uk> Date: Sun, 19 Apr 1998 22:46:14 +0100 From: Karl Pielorz Organization: TDX X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Terry Lambert CC: allen campbell , hackers@FreeBSD.ORG Subject: Re: (was Discussion : Using DHCP) - Now 'Config Databases' References: <199804192133.OAA14057@usr08.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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! 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