📅 Original date posted:2012-06-19
📝 Original message:On Tue, Jun 19, 2012 at 11:05:20AM +0200, Mike Hearn wrote:
> OK, to make progress on this work I need a few decisions (Gavin?)
>
> 1) Shall we do it?
I'm all for moving away from BDB. It's a very good system for what it is
intended for, but that is not how we use it. The fact that it is tied to
a database environment (but people want to copy the files themselves
between systems), that is provides consistency in case of failures (but
because we remove old log files, we still see very frequent corrupted
systems), the fact that its environments are sometimes not even forward-
compatible, ...
Assuming LevelDB is an improvement in these areas as well as resulting in
a speed improvement, I like it.
> 2) LevelDB is obscure, new and has a very minimalist build system. It
> supports "make" but not "make install", for example, and is unlikely
> to be packaged. It's also not very large. I suggest we just check the
> source into the main Bitcoin tree and link it statically rather than
> complicate the build.
How portable is LevelDB? How well tested is it? What compatibility
guarantees exist between versions of the system?
I don't mind including the source code; it doesn't seem particularly
large, and the 2-clause BSD license shouldn't be a problem.
> 3) As the DB format would change and a slow migration period
> necessary, any other tweaks to db format we could make at the same
> time? Right now the key/values are the same as before, though using
> satoshi serialization for everything is a bit odd.
>
> We'd need UI for migration as well.
Jeff was working on splitting the database into several files earlier, and
I'm working on the database/validation logic as well. Each of these will
require a rebuild of the databases anyway. If possible, we should try to
get them in a single release, so people only need to rebuild once.
PS: can we see the code?
--
Pieter
Pieter Wuille [ARCHIVE] /
npub1tj…jtl6r
2023-06-07 10:17:37
in reply to nevent1q…9dgc
Author Public Key
npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6rPublished at
2023-06-07 10:17:37Event JSON
{
"id": "259347b0af29488154876c7ab162dcb2815759c683be2c3e0fb84e299c8473de",
"pubkey": "5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6",
"created_at": 1686133057,
"kind": 1,
"tags": [
[
"e",
"04f378001a224b61fbc2cdf06fef1e31477c4fe54d08e030aa71e61ff8312ae3",
"",
"root"
],
[
"e",
"a428da9c1edad9614a9a3b49e1d298051a8ec6b3247051481de60267494736f9",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2012-06-19\n📝 Original message:On Tue, Jun 19, 2012 at 11:05:20AM +0200, Mike Hearn wrote:\n\u003e OK, to make progress on this work I need a few decisions (Gavin?)\n\u003e \n\u003e 1) Shall we do it?\n\nI'm all for moving away from BDB. It's a very good system for what it is\nintended for, but that is not how we use it. The fact that it is tied to\na database environment (but people want to copy the files themselves\nbetween systems), that is provides consistency in case of failures (but\nbecause we remove old log files, we still see very frequent corrupted\nsystems), the fact that its environments are sometimes not even forward-\ncompatible, ...\n\nAssuming LevelDB is an improvement in these areas as well as resulting in\na speed improvement, I like it.\n\n\u003e 2) LevelDB is obscure, new and has a very minimalist build system. It\n\u003e supports \"make\" but not \"make install\", for example, and is unlikely\n\u003e to be packaged. It's also not very large. I suggest we just check the\n\u003e source into the main Bitcoin tree and link it statically rather than\n\u003e complicate the build.\n\nHow portable is LevelDB? How well tested is it? What compatibility\nguarantees exist between versions of the system?\n\nI don't mind including the source code; it doesn't seem particularly\nlarge, and the 2-clause BSD license shouldn't be a problem.\n\n\u003e 3) As the DB format would change and a slow migration period\n\u003e necessary, any other tweaks to db format we could make at the same\n\u003e time? Right now the key/values are the same as before, though using\n\u003e satoshi serialization for everything is a bit odd.\n\u003e \n\u003e We'd need UI for migration as well.\n\nJeff was working on splitting the database into several files earlier, and\nI'm working on the database/validation logic as well. Each of these will\nrequire a rebuild of the databases anyway. If possible, we should try to\nget them in a single release, so people only need to rebuild once. \n\nPS: can we see the code?\n\n-- \nPieter",
"sig": "e5af6fd0b54487aa4397150d34316f78e5920c7531fcd45de84385da2c1d4e7bc7dba5eb4c43dbfe06717bde825fec9a8f9887c30b272ea3d06bcb9c8fc6f20d"
}