Date: Mon, 12 May 2008 08:47:53 -0700 From: Jeremy Chadwick <koitsu@freebsd.org> To: Anders Nore <andenore@start.no> Cc: freebsd-hackers@freebsd.org Subject: Re: Adding .db support to pkg_tools Message-ID: <20080512154753.GA16847@eos.sc1.parodius.com> In-Reply-To: <op.ua1q7ujn2n4ijf@duckjen.nextgentel.no> References: <op.uavxx8ip2n4ijf@duckjen.nextgentel.no> <20080509124308.GA596@britannica.bec.de> <9FC19AC2-DAD8-418C-8B9C-F129DEC58CEF@gmail.com> <20080511190741.GB47383@lizzy.catnook.local> <op.ua1q7ujn2n4ijf@duckjen.nextgentel.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, May 12, 2008 at 05:12:56PM +0200, Anders Nore wrote: > On Sun, 11 May 2008 21:07:41 +0200, Jos Backus <jos@catnook.com> wrote: > >> On Sun, May 11, 2008 at 06:38:25AM -0700, Garrett Cooper wrote: >>> +1. BDB is quite easy to corrupt... >> >> If we're going to use a binary file format, please consider using SQLite >> instead. It has the right license, a nice API (transactions!) and is >> robust >> enough for yum to use it for a similar purpose. >> > > One of the reasons for using BDB is that it is in the base system, SQLite > however is not. Interesting discussion, and there's some irony in it (SQLite uses a very BDB-like a storage medium, despite being a relational database system). SQLite's license is compatible/friendly, its API is decent, the source is fairly small and binary footprint (disk and memory both) are small, and it includes tools for dumping databases to ASCII so developers aren't forced to write DB dumping tools and users don't have to resort to using hexdump. A few things worth pointing out: With regards to DB1.x being easily corrupted, this is true, and I have heard claims of it from a couple developer-folk I worked with many years ago at Best Internet. On the other hand, SQLite appears to have a history of this as well, although those bugs have been fixed each and every time: http://www.sqlite.org/cvstrac/wiki?p=DatabaseCorruption Secondly, the following FAQ entry and documentation from Mozilla is of concern, specifically the last paragraph of the FAQ entry, since there is ongoing work in the ports collection to support parallel building, which would surely use fork() or locks): http://www.sqlite.org/faq.html#q6 http://developer.mozilla.org/en/docs/Storage#SQLite_Locking Thirdly, there is the concern of disk space. There are a substantial number of users who have FreeBSD on embedded systems or systems with little or no space, who use binary packages (pkg_add -r), which of course still makes use of /var/db/pkg. SQLite DBs grow over time, and don't shrink in size unless you use auto-vacuum mode or execute the VACUUM query: http://www.sqlite.org/faq.html#q12 Fourthly, it doesn't sound as if storage SQLite databases on an NFS mount is a good idea, and I've a feeling some people have /var NFS mounted (diskless systems for example): http://www.sqlite.org/faq.html#q5 Finally, there's the concern about the SQLite file format changing. Sometimes they're backwards-compatible, other times not. http://www.sqlite.org/formatchng.html http://www.sqlite.org/fileformat.html Just stuff to consider. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080512154753.GA16847>