On Mon, 2007-04-30 at 05:16 +0000, Nate Nielsen wrote: > I was put off by the fact that Evolution, NSS, and many other projects > have Berkeley DB as part of their source rather than depending on it as > a library. > > Anyone with inside know if this is due to incompatibilities between > versions or other instabilities? There have been db file format changes in the past. Sleepycat people swear up and down that it hasn't changed in ages, though, which I tend to believe. What has changed, unsurprisingly, is the APIs you use to talk to bdb. Especially in mid 3.0 and then the transition through 4.0 to 4.1 there was all kinds of API craziness. Evolution was first using db in the 3.0 days, and they got so sick of dealing with the (then) fact that they couldn't guarantee a required and working version of db being installed that they gave up trying and shipped one they could link against it in their own sources. Time has passed, however. For one thing, distros across the board are better about slotting (aka parallel installing) libraries. For another, upstream projects have gotten better about not causing API breaks within those slots, with the net result that I would judge DB 4.2 a solidly stable and widely available target to depend upon. > Also Berkeley is a database that seems to need maintenance, from > experiences administering OpenLDAP and other systems. It comes with > various tools to this end. [Most of which you can call programmatically, for what it's worth] > Is it in fact usable a 'store and forget' type db? I spent about 6 months using Berkeley DB, and was fairly impressed. That said, it does have its complexities. If you're storing key -> blob data as a cache, then it should be great. As a long term persistent database for data that changes schema, I'd look elsewhere, but that is of course a bigger problem. [As it happens, we were working in the Java bindings to DB; right when we discovered the pain of trying to encoding complex hierarchical data [in any database] is when we discovered db4o and we haven't looked back; C side, though, DB is hard to beat as an embedded hash store for the sheer get-it-done factor] AfC Sydney -- Andrew Frederick Cowie Technology strategy, managing change, establishing procedures, and executing successful upgrades to mission critical business infrastructure. http://www.operationaldynamics.com/ Sydney New York Toronto London
Attachment:
signature.asc
Description: This is a digitally signed message part