Skip to content
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

Can I store and search data in bytes? #111

Open
oguzdelioglu opened this issue Nov 15, 2021 · 3 comments
Open

Can I store and search data in bytes? #111

oguzdelioglu opened this issue Nov 15, 2021 · 3 comments

Comments

@oguzdelioglu
Copy link

I'm storing as bytes, but I can't search for bytes.

<Error index error: argument must be a string: []byte{0xc6, 0x1b, 0x9b, 0xb3, 0xa7, 0xa0, 0x76, 0x7e, 0x31, 0x79, 0x71, 0x3f, 0x3a, 0x5c, 0x7a, 0x9a, 0xed, 0xce, 0x19, 0x3c}

@oguzdelioglu
Copy link
Author

type DBAddress struct {
	address []byte
}

schema := &memdb.DBSchema{
Tables: map[string]*memdb.TableSchema{
	"addressList": {
		Name: "addressList",
		Indexes: map[string]*memdb.IndexSchema{
			"id": {
				Name:    "id",
				Unique:  true,
				Indexer: &memdb.StringFieldIndex{Field: "address"},
			},
		},
	},
},
}


it, err := txn.Get("addressList", "id", hash)

@dnephin
Copy link
Contributor

dnephin commented Nov 15, 2021

Thank you for your interesting in go-memdb!

I believe the problem is the use of StringFieldIndex. This indexer uses https://pkg.go.dev/reflect#Value.String when creating an index from the struct. As it says on that docstring reflect.Value.String() is able to convert the []byte into a string, so it doesn't error when you index.
However the StringFieldIndex expects the args passed to txn.Get to always be a string, it doesn't do the same conversion. It looks like #58 is the same issue.

This failure scenario is a bit surprising (I would have expected it to error when trying to index, instead of when trying to query), but otherwise I believe is behaving correctly. StringFieldIndex is only intended to work with string fields, not []byte.

I think to index a []byte you'll want to build an indexer that implements both https://pkg.go.dev/github.com/hashicorp/go-memdb#SingleIndexer and https://pkg.go.dev/github.com/hashicorp/go-memdb#Indexer, optionally it could also implement https://pkg.go.dev/github.com/hashicorp/go-memdb#PrefixIndexer if you need to do prefix lookups.

I cover the details of writing a customer indexer a bit more in this comment: #97 (comment)

@oguzdelioglu
Copy link
Author

Thank you for your interesting in go-memdb!

I believe the problem is the use of StringFieldIndex. This indexer uses https://pkg.go.dev/reflect#Value.String when creating an index from the struct. As it says on that docstring reflect.Value.String() is able to convert the []byte into a string, so it doesn't error when you index. However the StringFieldIndex expects the args passed to txn.Get to always be a string, it doesn't do the same conversion. It looks like #58 is the same issue.

This failure scenario is a bit surprising (I would have expected it to error when trying to index, instead of when trying to query), but otherwise I believe is behaving correctly. StringFieldIndex is only intended to work with string fields, not []byte.

I think to index a []byte you'll want to build an indexer that implements both https://pkg.go.dev/github.com/hashicorp/go-memdb#SingleIndexer and https://pkg.go.dev/github.com/hashicorp/go-memdb#Indexer, optionally it could also implement https://pkg.go.dev/github.com/hashicorp/go-memdb#PrefixIndexer if you need to do prefix lookups.

I cover the details of writing a customer indexer a bit more in this comment: #97 (comment)

There are about 70 million pieces of data.
I have to convert them to bytes and add them to the database like this.

In this way, it provides both less ram consumption and faster search.

Thank you for your interest.
Unfortunately, I couldn't find what I wanted in the codes you sent.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants