On 2007-May-12 11:09:35 +0200, Michel Talon <[EMAIL PROTECTED]> wrote: >- first i don't suppose sqlite3 is busted, since i suppose it is in the > base system and it works by definition.
It can happen that base system utilities become unusable for various
reasons: Maybe an installworld went wrong, maybe someone accidently
deleted a shared library, maybe the disk developed an inconvenient
bad sector. If sqlite3 is being used solely for ports management
then it may be a reasonable assumption that sqlite3 is always working
but if (as has been suggested) SQLite is used for base system config
files then it is essential that those files be repairable.
> Your hypothesis is alike, what
>do i do to edit my config files if vi and ed are busted?
Use emacs :-)
Seriously, you can probably get away with sh builtins for most purposes:
while read line
do
case "$line" in
foo*) echo bar ;;
*) echo "$line" ;;
esac
done < file > file.tmp
mv file.tmp file
> Moreover if
>sqlite3 gets really busted i can import a copy and hope it works,
I agree that sqlite3 is good in this respect. "Import" implies that
you are able to get the system to a point where it can communicate
externally without needing whatever tool is broken.
>- second, if i am sql allergic, it takes one command to export the table
> to a straight file,
This is only usable if the schema is designed so that the tables are
reasonably independent. It's certainly possible to design something
that could not be usefully exported table-by-table and edited.
>- is the cost of including sqlite in the base system so high that
>the above benefits are insufficient? Personnally i don't know, but i
>think some discussion is at least in order.
I agree that this topic is worth discussing. There is a very high bar
for including new utilities in the base system because every time a
new utility is added, the maintenance effort goes up. So far I
haven't seen anything that would make me say "SQLite should be imported".
>- and finally to answer one of Bill's critiques, why sqlite rather than
>a Berkeley database? Precisely because sqlite offer a lot of facilities
>that Berkeley db doesn't offer, such as export and import to and from
>csv files,
This is a function of sqlite3(1) rather than the SQLite database itself.
It wouldn't be that difficult to write a tool to convert a BDB into
a flat file of key,value pairs.
> auto documentation of the table contents,
This is a big plus for SQL.
> while it requires
>in fact programming and knowledge of the api of the database to hand
>edit the Berkeley db.
Very trivial effort - if we had a need for it, someone could write the
necessary few dozen lines and commit it. The downside is that since
BDB isn't self documenting, a flat file may not be any use.
--
Peter Jeremy
pgp4DdQEuksZO.pgp
Description: PGP signature
