-
Notifications
You must be signed in to change notification settings - Fork 622
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
CASSGO-26 consistency serial was added #1837
base: trunk
Are you sure you want to change the base?
CASSGO-26 consistency serial was added #1837
Conversation
76a1c5f
to
2d83ec8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't we just remove SerialConsistency
altogether and use Consistency
everywhere with these changes? I think it would make no difference and we'd get rid of a type that no longer has a reason to exist. Also we're missing a check on the ClusterConfig
serial consistency to ensure it's a valid value.
On the other hand we could also keep SerialConsistency
around to ensure that only SERIAL
or LOCAL_SERIAL
can be used when setting the serial consistency level. But to do this we couldn't make it type SerialConsistency = Consistency
like it is on this PR. We'd have to keep the previous code for SerialConsistency
AND add a Serial
+LocalSerial
for the Consistency
type...
I believe that other drivers don't have a separate consistency level type for SERIAL CONSISTENCY so I'm +1 on the first option (i.e. remove SerialConsistency
completely and just use Consistency
everywhere with appropriate checks when setting the serial consistency).
@joao-r-reis I had an idea to implement it as you said in the first option, but it's the breaking changes, so I decided to keep backward compatibility. In case this feature is added to v2, there is no reason to leave |
2d83ec8
to
3662be4
Compare
Hmm what about if we have |
So basically the only change we would add to this PR is make sure that |
session.go
Outdated
@@ -144,6 +144,10 @@ func NewSession(cfg ClusterConfig) (*Session, error) { | |||
return nil, errors.New("Can't use both Authenticator and AuthProvider in cluster config.") | |||
} | |||
|
|||
if cfg.Consistency.IsSerial() { | |||
return nil, fmt.Errorf("the default consistency level is not allowed to be SERIAL or LOCAL_SERIAL. Recived value: %v", cfg.Consistency) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it's fine if Consistency
has SERIAL
or LOCAL_SERIAL
(it won't work with writes but sure, maybe the app only has reads). I meant that cfg.SerialConsistency
has to be SERIAL
or LOCAL_SERIAL
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, it slipped my mind that consistency could be SERIAL for read operation, thank you for noticing it.
3662be4
to
be2bc58
Compare
Looks good, please format your commit message following the rules stated in CONTRIBUTING.md and add this JIRA to the We need another committer +1 to merge this. |
I like this idea, it will solve the issue |
accb87e
to
a18e16e
Compare
frame.go
Outdated
EachQuorum Consistency = 0x07 | ||
LocalOne Consistency = 0x0A | ||
Serial Consistency = 0x08 | ||
LocalSerial Consistency = 0x09 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NIT: move Serial
and LocalSerial
above LocalOne
to maintain sequential order.
if cfg.SerialConsistency > 0 && !cfg.SerialConsistency.IsSerial() { | ||
return nil, fmt.Errorf("the default SerialConsistency level is not allowed to be anything else but SERIAL or LOCAL_SERIAL. Recived value: %v", cfg.SerialConsistency) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about adding a test for this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And overall, how about adding another test to verify that these two consistency levels are allowed for use?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have added some tests to cover each consistency level, please check it
57f784b
to
769a5c1
Compare
The user should be able to set consistency to SERIAL or LOCAL_SERIAL for Paxos reads, but the previous implementation doesn't support such a feature. patch by Mykyta Oleksiienko; reviewed by João Reis for CASSGO-26
769a5c1
to
e963b69
Compare
Closes #1832
With the previous implementation, setting consistency SERIAL for Paxos reads was impossible. Fixed in this PR