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>