Switch to bbolt

[jeanlucmongrain]

boltdb/bolt@fa5367d

[asdine]

I'd love to but i'm afraid that would break code using bolt directly or passing bolt options to storm when opening the database. WDYT ?

[bep]

Right now they are 58 commits on top of Bolt, mostly technical stuff. At some point we will most likely "really want it", so taking that pain now would probably be better. Which means that one has to abstract the "direct db access" and add a bolt and bbolt package that the user can then select. How easy that is I have not looked at, but it sounds doable.

[asdine]

Right now they are 58 commits on top of Bolt, mostly technical stuff. At some point we will most likely "really want it", so taking that pain now would probably be better

I totally agree but i'm mostly worried about versioning and compatibility. People should be able to select a range as wide as >= 1.0.0, < 2.0.0 with Storm without fearing to have a breaking build.
Also maintaining support for both libraries might add some unnecessary work IMO.

Should we move to a v2 now with full support of bbolt? We'd keep v1.x exclusively for backporting bug fixes and bolt support. v2 would simply contain bbolt instead of bolt.

WDYT?

[bep]

Should we move to a v2 now with full support of bbolt?

Yes, please! And I agree about the "maintaining part". The most important customer in a project like this is yourself.

[jeanlucmongrain]

IMHO, I can only guess that if Boltdb is going to stay in a maintenance mode, where only critical bugs are fixed and never get any improvement, the bolt and storm users base will move to bbolt, or wish to move if their dependencies are following as well.

Storm is maintained but Boltdb is not. Which is an important decision factor to choose or not Storm.

I'd love to but i'm afraid that would break code using bolt directly or passing bolt options to storm when opening the database. WDYT ?

Sure it will break compatibility, but overall it's better for the greater good of any Storm users.

Users that don't want to refactor their code can just vendor a "fake" boltdb and use Go 1.9 type alias that point to bbolt. but I can only guess it's easier to perform a simple refactor instead.

[siginfo]

What is the consensus? moving to bbolt or staying with bolt?

I agree with @bep to bite the bullet sooner than later.

IMHO, it seems that bbolt has been battle tested in real environments and most of the changes are related performance and stability.

[asdine]

The consensus is to move Storm to v2 with Bbolt instead of Bolt.
v2 will be the master branch and v1 will have its own branch.

The current v1 will keep using Bolt and will only benefit from future Storm bug fixes, no new Storm feature.

I'll try to publish the v2 as soon as i can (in the next few days).

I'll also take this opportunity to clean the code a little bit, if you have suggestions please shoot 👍

[joeblew99]

Is there any interest in supporting Badger ?
It just got proper transaction support

Bleve is also supporting Badger whilst also supporting bolt.

My main reason to switch is the much higher write performance. My benchmarks are giving me about 10 times high write perf on server and about 8 times on arm mobile.

The support from the team behind Badger is also pretty good. I don't see them going away for a while..

[asdine]

Sorry for the huge delay guys ! I have published a v2.0.0-rc.1 tag. It uses bbolt instead of bolt and contains some needed cleanups.
Some APIs have been slighly changed but the v1 database is supposed to be compatible with the v2 codebase
Can you guys test it on your own projects and report anything that's broken please ?

[asdine]

@joeblew99 Concerning Badger this is very interesting indeed, but switching to it for the v2 is impossible. But this is a really good idea for the Storm v3 who will be a complete rewrite.