Create new cassandra table "operation_names_v2" with "spanKind" column for operation name index #1937
Conversation
guo0693
requested review from
black-adder,
jpkrohling,
objectiser,
pavolloffay,
tiffon,
vprithvi and
yurishkuro
as code owners
| @@ -91,7 +91,7 @@ func TestCassandraFactory(t *testing.T) { | |||
| _, err = f.CreateArchiveSpanWriter() | |||
| assert.EqualError(t, err, "archive storage not configured") | |||
|
|
|||
| f.archiveConfig = &mockSessionBuilder{} | |||
| f.archiveConfig = newMockSessionBuilder(session, nil) | |||
There was a problem hiding this comment.
Have to pass the mock session so that operation names table check can pass
Codecov Report
@@ Coverage Diff @@
## master #1937 +/- ##
==========================================
- Coverage 98.46% 98.44% -0.02%
==========================================
Files 198 198
Lines 9744 9794 +50
==========================================
+ Hits 9594 9642 +48
- Misses 114 115 +1
- Partials 36 37 +1
Continue to review full report at Codecov.
|
…n for operation name index - add migration script - read from the latest table if available, otherwise fail back to previous table Signed-off-by: Jun Guo <[email protected]>
|
Tested in local env, the code works with both old and new table |
Signed-off-by: Jun Guo <[email protected]>
| } else { | ||
| assert.EqualError(t, err, "Error reading operation_names from storage: "+expErr.Error()) | ||
| assert.EqualError(t, err, fmt.Sprintf("Error reading %s from storage: %s", schemas[test.schemaVersion].tableName, test.expErr.Error())) |
There was a problem hiding this comment.
arguments to assert functions are already treated as printf args, you don't need additional fmt.Sprintf
There was a problem hiding this comment.
I tried, but it failed.
func EqualError(t TestingT, theError error, errString string, msgAndArgs ...interface{}) bool
fmt.Sprintf is used to generate the errString, without fmt.Sprintf, it will treat "schemas[test.schemaVersion].tableName, test.expErr.Error()" as msg args for the output when the assert fail
Signed-off-by: Jun Guo <[email protected]>
| {name: "test new schema without error", schemaVersion: latestVersion, expErr: nil}, | ||
| {name: "test new schema with scan error", schemaVersion: latestVersion, expErr: scanError}, | ||
| } { | ||
| t.Run(fmt.Sprintf("%s", test.name), func(t *testing.T) { |
There was a problem hiding this comment.
I have optimized to use t.Run(test.name, func) in the PR 1921-3. Try to avoid update it in 2nd branch and merge into 3rd branch again.
|
why is the build failing? |
Because the t.run is using fmt.Sprintf("%s", test.name), instead of test.name directly. I fixed it in the PR 1921-3 when I merge this branch into 1921-3 last night before travis throw this error. I don't want to change this branch and solve merge conflict again in 1921-3 since the build will pass when I merge 1921-3 to this branch. My plan is:
|
|
We do not merge non-compiling PRs to master. Why is it so difficult to apply the t.Run to two lines? If it matches another branch, there won't be merge conflicts. |
We are not going to merge non-compiling PRs to master. Both 1921-2 and 1921-3 touched the same files, therefore everytime I touch operation_names.go and test, I have to solve merge conflicts in 1921-3. I have repeated that several times yesterday, feel like it's not the right way. In general, I want to propose a process for working on the big feature changes in the future:
What do you think? In this case 1921-1 is already merged, we kind of missed the train for this feature. Next time we could use this methodology. |
|
If you are OK with above, can i get a stamp on guo0693#1 first? |
|
I don't understand the workflow you're proposing. Merging something into this PR will require another top to bottom review, how does it make reviewing easier? |
"We should not do code changes directly in feature branch." Each individual PR is reviewed separately. As long as there is no un-necessary code changes in feature branch (solving merged conflict in the last step is necessary code change, and the single last commit can be easily reviewed), we don't need another top to bottom review. Here, we need to make sure:
|
|
Btw, at the same time, I pushed changes to fix the travis build in this branch, also rebased 1921-3 onto this branch. You don't need to go over the 1921-3 from top to bottom, the rebase doesn't lead to any code changes. It's probably easier to go over the workflow in person on a whiteboard when you are back :) |
Signed-off-by: Jun Guo [email protected]
Which problem is this PR solving?
Short description of the changes