In <[EMAIL PROTECTED]>, Michel Talon <[EMAIL PROTECTED]> typed:
> On Fri, May 11, 2007 at 10:01:46PM -0400, Mike Meyer wrote:
> > In <[EMAIL PROTECTED]>, Michel Talon <[EMAIL PROTECTED]> typed:
> > > One of the most obvious being that the sqlite database can be edited
> > > as easily as a pure textfile using the sqlite3 program
> > Huh? They can? With a pure textfile, if vi is busted, I can use ed. If
> > ed is also busted, I can use sed. What do I use on an sqlite database
> > if sqlite3 is busted?
> - first i don't suppose sqlite3 is busted, since i suppose it is in the
> base system and it works by definition. Your hypothesis is alike, what
> do i do to edit my config files if vi and ed are busted? Moreover if
> sqlite3 gets really busted i can import a copy and hope it works, it
> requires very few libraries and other files, not much more than vi,
> plus the sqlite3 library, of course. The combined size of sqlite3
> and libsqlite3 is less than 400k.
You missed the point. The claim was "the sqlite database can be edited
as easily as a pure textfile." I claim this is not always true. In
particular, since someone has already mentioned using SQL for system
config file instead of just the pkackage db, if your system has
suffered a major failure such that commands in the base system - like
vi, ed, etc. - are busted, then sqlite (whether it's part of the base
system or not) can equally well be be broken. With flat text, there
are lots of tools in the base system that can be used for dealing with
them if one (or more) is broken. By your own admission, if sqlite is
so broken, the only alternative is to get another copy. Under these
circumstances, sqlite can *not* be "edited as easily as pure text
file".
> - second, if i am sql allergic, it takes one command to export the table
> to a straight file, each row in a line, each field separated by | or
> anything else of my choice. Exactly the same tools that you have
> mentioned allow to edit this file, and then one command allows to load
> it in the database.
The point of the second question wasn't that some people are allergic
to SQL - the point was that pure text files are different from SQL,
and two have different sets of strengths in weaknesses. In this case,
a strength of a pure text file is that it's easy to ignore record and
field boundaries when operating on it. This kind of thing is hard to
do in SQL, so that the easiest way to do it may well be the one you
suggested - convert it to flat text, transform it, and convert
back. Once again, sqlite can not be "edited as easiliy as a pure text
file".
That said, the first case isn't crucial for the ports/packages
db. Your system will boot and pretty much run fine if that database is
screwed up, so importing a new copy to fix things isn't
unreasonable. I also agree that the need for performance in the ports
db is such that using a binary database of some kind is probably
justified - because speed isn't one of the strengths of pure text
files.
Whether or not SQL brings enough to the table to justify adding
sqllite to the base system when compared to tools that are already
there is another issue.
<mike
--
Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
