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

No way to detect if value not found when using Client.Get #64

Open
jonbonazza opened this issue Jul 27, 2017 · 2 comments
Open

No way to detect if value not found when using Client.Get #64

jonbonazza opened this issue Jul 27, 2017 · 2 comments

Comments

@jonbonazza
Copy link
Contributor

@timoha We have come across a pretty major issue. When using Client.Get, if no result is found in HBase, HBase will return an RPC with no value and no error. The gohbase client will take this rpc response and return an empty *hrpc.Result and no error. A workaround is to check the resulting *hrpc.Result and make sure it's not the zero value, working under the assumption that a zero value hrpc.Result is never valid.

I am fairly certain that the resulting code is here:

// ToLocalResult takes a protobuf Result type and converts it to our own
// Result type in constant time.
func ToLocalResult(pbr *pb.Result) *Result {
        // We should return nil here, not an empty struct.
	if pbr == nil {
		return &Result{}
	}
        // ...
}

I can submit a PR for this if you wish, but I wanted to check in here to ensure that there wasn't some specific reason that an empty struct is returned here.

@timoha
Copy link
Collaborator

timoha commented Aug 9, 2017

Well, it depends on how you define an empty case.
In our codebase, if we have an empty result (no cells), that means that no values have been found. It kind of makes the code nicer as we don't have to check if res == nil, but instead just check len(res.Cell) == 0.

Maybe it would be nicer to return nil instead of empty hrpc.Result, I don't have strong preference though. If nothing is found, then you'll have nil, nil returned, which is kind of strange also?

@jonbonazza
Copy link
Contributor Author

@timoha thinking about this more, the standard approach to something like this seems to be to return a specific error (i.e. ErrNoResults) along with a nil Result. What are your thoughts on this approach? For now, we are using len.

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