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

Add support for nil partition key for secondary indexes in memory connector #414

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

aniketpant
Copy link

@aniketpant aniketpant commented Dec 14, 2019

Why:
Cassandra supports secondary indexes where the partition key can be
nil. This results in the index not being generated until the value is
set. The test client which uses a memory connector should support the
same behavior.

This change addresses the need by:
Add a nil check in partitionKeyBuilder which is capable of handling
different value types. In these cases, we simply skip over the value
instead of encoding a nil value which results in a panic inside the
gob encoder.

connector

Why:
Cassandra supports secondary indexes where the partition key can be
nil. This results in the index not being generated until the value is
set. The test client which uses a memory connector should support the
same behavior.

-

This change addresses the need by:
Add a `nil` check in `partitionKeyBuilder` which is capable of handling
different value types. In these cases, we simply skip over the value
instead of encoding a `nil` value which results in a panic inside the
gob encoder.

-
@@ -93,6 +93,9 @@ func partitionKeyBuilder(pk *dosa.PrimaryKey, values map[string]dosa.FieldValue)
var encodedKey []byte
for _, k := range pk.PartitionKeys {
if v, ok := values[k]; ok {
if isNilInterface(v) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not just v == nil?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tired doing that at first but seems like it's one of those interface issues where an interface holding a nil value will be non-nil. An alternative to isNilInterface would be using reflection.

func isNilValue(i interface{}) bool {
    return i == nil || reflect.ValueOf(i).IsNil()
}

Example: https://play.golang.org/p/j9SqfEgGe4B

Ref: https://tour.golang.org/methods/12

Note that an interface value that holds a nil concrete value is itself non-nil.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@phliar Do you know if there's an alternative here? See my comment on the issue I'm experiencing and why we need to cast to the interface.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your proposed PR is a more efficient way of doing it than adding a reflect call. A golang interface contains both a Type and a Value, and you only want to see if the Value is nil.
At this point in the code, the Type will never be nil, and so checking if the interface is nil will always be false.

There's a longer discussion of this here: https://groups.google.com/forum/#!topic/golang-nuts/wnH302gBa4I/discussion

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this totally makes sense now.

I wanted to avoid using reflect here primarily because we are always going to deal with known types here.

@@ -714,6 +717,28 @@ func getStartingPoint(ei *dosa.EntityInfo, token string) (start string, startPar
return start, startPartKey, nil
}

func isNilInterface(v dosa.FieldValue) bool {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isNilInterface could use a unit test

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right. Will add one.

@CLAassistant
Copy link

CLAassistant commented Mar 22, 2020

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

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

Successfully merging this pull request may close these issues.

4 participants