Guidance on Badger migration from v1 to v2 #1208
Comments
|
Hey @dopey, thanks for reporting the issue. I see the following issue while trying to use badger v1.6 and v2 in the same project This looks like an issue is with the protobuf files that we generate.
As of now, I can't think of a way for you to support both the versions. I'll try to find a fix for this (maybe we're versioning the protobuf file incorrectly?) and get back to you. |
jarifibrahim
added
status/accepted
|
@jarifibrahim did you end up digging into this? I have a project where I'd love to use badger v2, but I can't, because one of my dependencies indirectly pulls badger v1. It's an unfortunate situation, as I can't fix the problem directly, and I can't import the current version. |
There were two instances of init-time work being incompatible with v1.
That is, if one imported both v1 and v2 as part of a Go build, the
resulting binary would end up panicking before main could run. The
examples below are done with the latest versions of v1 and v2, and a
main.go as follows:
package main
import (
_ "github.com/dgraph-io/badger"
_ "github.com/dgraph-io/badger/v2"
)
func main() {}
First, the protobuf package used "pb" as its proto package name. This is
a problem, because types are registered globally with their fully
qualified names, like "pb.Foo". Since both badger/pb and badger/v2/pb
tried to globally register types with the same qualified names, we'd get
a panic:
$ go run .
panic: proto: duplicate enum registered: pb.ManifestChange_Operation
goroutine 1 [running]:
github.com/golang/protobuf/proto.RegisterEnum(...)
.../go/pkg/mod/github.com/golang/protobuf@v1.3.1/proto/properties.go:459
github.com/dgraph-io/badger/v2/pb.init.0()
.../badger/pb/pb.pb.go:638 +0x459
To fix this, make v2's proto package fully qualified. Since the
namespace is global, just "v2.pb" wouldn't suffice; it's not unique
enough. "dgraph.badger.v2.pb" seems good, since it follows the Go module
path pretty closely.
The second issue was with expvar, which too uses globally registered
names:
$ go run .
2020/04/08 22:59:20 Reuse of exported var name: badger_disk_reads_total
panic: Reuse of exported var name: badger_disk_reads_total
goroutine 1 [running]:
log.Panicln(0xc00010de48, 0x2, 0x2)
.../src/log/log.go:365 +0xac
expvar.Publish(0x906fcc, 0x17, 0x9946a0, 0xc0000b0318)
.../src/expvar/expvar.go:278 +0x267
expvar.NewInt(...)
.../src/expvar/expvar.go:298
github.com/dgraph-io/badger/v2/y.init.1()
.../badger/y/metrics.go:55 +0x65
exit status 2
This time, replacing the "badger_" var prefix with "badger_v2_" seems
like it's simple enough as a fix.
Fixes #1208.
What version of Go are you using (
go version)?What version of Badger are you using?
1.6
I work on an OSS project (https://github.com/smallstep/certificates) that uses a database abstraction layer allowing the user to select different databases at run time. One of our users recently opened a ticket asking us to support badger v2. I thought we might be able to just add badger/v2 as an additional db option, but it appears that when I load v1 and v2 in the same project I get a golang panic because some common code is being instantiated from the init.go of each package.
Currently we have some users who are running badger v1 and other users who would like to start using badger v2. If we could easily support both for a period of time (while we encourage v1 users to migrate) that would be great. But I'm not sure there is any easy way to do this (please let me know if there is). Assuming this isn't possible, do you have any recommendation on a course of action that wouldn't immediately require old users to migrate their DBs?
The text was updated successfully, but these errors were encountered: