Date: Sat, 12 May 2007 11:09:35 +0200 From: Michel Talon <talon@lpthe.jussieu.fr> To: Mike Meyer <mwm@mired.org> Cc: freebsd-hackers@freebsd.org Subject: Re: DPS Initial Ideas Message-ID: <20070512090935.GA13929@lpthe.jussieu.fr> In-Reply-To: <17989.8202.624522.136573@bhuda.mired.org> References: <20070512004209.GA12218@lpthe.jussieu.fr> <17989.8202.624522.136573@bhuda.mired.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, May 11, 2007 at 10:01:46PM -0400, Mike Meyer wrote: > In <20070512004209.GA12218@lpthe.jussieu.fr>, Michel Talon <talon@lpthe.jussieu.fr> 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? Answering both you and Bill Moran: - 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. - 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. - so what are the benefits? They are that non sql impaired people can make good use of the power of sql queries to simplify their work. And this without reducing the possibilities of sql impaired people. Moreover one can use general tools like graphic sql tools to present the contents of the database to the end user in a pleasant way if it is desired. And finally it may be that the transactional properties of sqlite can be used to gain better reliablity. - 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. - 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, auto documentation of the table contents, while it requires in fact programming and knowledge of the api of the database to hand edit the Berkeley db. Anyways, i have read that Marc Espie is envisioning using sqlite3 for OpenBSD package system, and that he is very satisfied with what he has seen up to now. If this enters production, perhaps this will confer BSD legitimity to such practices ... Seriously, the FreeBSD package system is in great need of a profound overhaul, pretending it works well is complete denial of reality. I hope that young people working on summer code projects will infuse *new* ideas, and not spend their vacations polishing inadequate tools. -- Michel TALON
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070512090935.GA13929>