To be truly database-agnostic, should we also allow the "sendz-all-your-coinz2whizz94" database ?
If someone wants to write the appropriate interface and it can support the functions, sure.
Topic: Re: Berkeley Database version 4.8 requirement unsustainable (Read 1835 times)
If someone wants to write the appropriate interface and it can support the functions, sure.
To be truly database-agnostic, should we also allow the "sendz-all-your-coinz2whizz94" database ?
Which is why ideally you want to make it as database agnostic as possible. If, for whatever reason, you want to use BDB 4.8, you should be perfectly able to with the only restriction being if new features are introduced which require newer database features.
There is no good reason to stick with 4.8 or even BDB other than "we haven't got around to fixing that yet"
To be clear, I don't even mind that we're locked to BDB that much but we are locked to 4.8 for the wrong reasons.
There is no good reason to stick with 4.8 or even BDB other than "we haven't got around to fixing that yet"
To be clear, I don't even mind that we're locked to BDB that much but we are locked to 4.8 for the wrong reasons.
It's my computer and I don't want to break known-good(enough) software with obligitory version number creep.
If the word "sustainable" is clarified to "perpetually sustainable" then we see the problem with upgrading from bdb4.8 to bdb6.2 which is certain to not work in twenty+ years' time. Therefore even if it is not everyone's ideal in 2015, the decision in 2009 to freeze at a distributable bdb4.8 instead of locking it to the contemporary version number escalator is the only perpetually sustainable way of getting it good enough and consistent. Are improvements to access to a bdb4.8 installer required? Vote here as the originator of this post did raise a valid query that one needs to be able to get the database in order to run a full node.
If the word "sustainable" is clarified to "perpetually sustainable" then we see the problem with upgrading from bdb4.8 to bdb6.2 which is certain to not work in twenty+ years' time. Therefore even if it is not everyone's ideal in 2015, the decision in 2009 to freeze at a distributable bdb4.8 instead of locking it to the contemporary version number escalator is the only perpetually sustainable way of getting it good enough and consistent. Are improvements to access to a bdb4.8 installer required? Vote here as the originator of this post did raise a valid query that one needs to be able to get the database in order to run a full node.
It's my computer and I don't want to install outdated software without good reason.
"Best viewed with Internet Explorer 3.0"
"Best viewed with Internet Explorer 3.0"
If we can't sometimes install a bit of "alien" database software then whose computer is it?
As soon as installing something without it being listed in the authorized app store is strictly forbidden, the marketing pigs will take over and demand payment every year just to unbreak what we bought last year. Wouldn't That be more unsustainable (==needless ongoing consumption of scarce resources) than having to maintain a 2009 database and installer ?
As soon as installing something without it being listed in the authorized app store is strictly forbidden, the marketing pigs will take over and demand payment every year just to unbreak what we bought last year. Wouldn't That be more unsustainable (==needless ongoing consumption of scarce resources) than having to maintain a 2009 database and installer ?
For now, I'm compiling it ignoring the incompatibility but since this is a solution I'm hoping to sell to others (maybe) I probably have to get the 4.8 working.
Having thought about it more, I've come to the conclusion that bitcoind should use whatever database internally when running (which is to say it shouldn't be locked into BDB 4.
but that the "wallet" should be a file exported from the client, probably in the same format at the JSON exported by Pywallet.
Having thought about it more, I've come to the conclusion that bitcoind should use whatever database internally when running (which is to say it shouldn't be locked into BDB 4.
but that the "wallet" should be a file exported from the client, probably in the same format at the JSON exported by Pywallet. 
Just trying to compile bitcoind tonight and this is *still* an issue. This is just crazy, so many open standards for data storage around (XML, JSON, CSV even) and we're stuck with some obsolete binary format?
If you need the features of a database, fine, implement a database but don't tie it to a specific implementation, don't treat it as the wallet and don't expect it to be portable.
If you need the features of a database, fine, implement a database but don't tie it to a specific implementation, don't treat it as the wallet and don't expect it to be portable.
I think you may be talking to satoshi
There's a repo maintained by Matt Corallo that has any of the bitcoin dependency oddities like BDB 4.8, amongst other stuff. Don't ask me where.
Just trying to compile bitcoind tonight and this is *still* an issue. This is just crazy, so many open standards for data storage around (XML, JSON, CSV even) and we're stuck with some obsolete binary format?
If you need the features of a database, fine, implement a database but don't tie it to a specific implementation, don't treat it as the wallet and don't expect it to be portable.
If you need the features of a database, fine, implement a database but don't tie it to a specific implementation, don't treat it as the wallet and don't expect it to be portable.
Jump to: