-
Notifications
You must be signed in to change notification settings - Fork 172
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace Berkeley DB database backend #2629
Comments
The deprecation is partially addressed by #2620 moving the BDB source into the source tree. SQLite is used by upstream and it's on my long list of patches to pull. |
Actually the bdb library IS maintained. The versions past 5.3 are under a different license (since Oracle) and most distributions are not comfortable with that. Arch appears to be an exception. Note that it is not the lack of maintenance that is the issue we are concerned about, as the scope of use by Gridcoin of this low level code is very narrow and specific. Rather it is the response of the Linux distributions to the Oracle licensing change, and the fact that some use 4.8 while others use 5.3+ that is the issue, because of the lack of backwards compatibility. As @div72 alluded to above, we have decided, in the short term, to roll the bdb 53 code into our source tree and standardize on that for a while until we can backport Bitcoin Core's newer wallet code and the SQLite option. |
Actually, according to Wikipedia, it is unmaintained.
|
Doesn't really matter. Given the narrow use we have, we don't particularly need updates. We will follow Bitcoin Core long before this becomes an issue. |
Quite frankly, I would love to use leveldb, but we would need to create a second instance, and since leveldb uses many files, people would have to transport a whole subdirectory, not just a single file, for portability. This is not really tenable IMO. |
Feature Request
Describe the Feature Request
Linux distributions, such as Gentoo, Fedora and Debian, started phasing-out Berkeley DB support because the library is effectively unmaintained.
Describe Preferred Solution
Use a modern replacement like GDBM (which has berkdb compatibility support), SQLite or LMDB. Maybe LevelDB since it's also used by the project.
Additional Context
The text was updated successfully, but these errors were encountered: