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 fake metadata store and fix tests. #958

Merged
merged 2 commits into from
Mar 21, 2019

Conversation

neuromage
Copy link
Contributor

@neuromage neuromage commented Mar 11, 2019

Also, add instructions on how to build/run the backend with Bazel.

Note that the fake metadata store works, but I need to add proper tests
that exercise it. That'll be done in a separate PR.

One thing I'm missing here is how to make Bazel run well in Travis. I
will send a follow up PR for doing this.


This change is Reviewable

Also, add instructions on how to build/run the backend with Bazel.

Note that the fake metadata store works, but I need to add proper tests
that exercise it. That'll be done in a separate PR.

One thing I'm missing here is how to make Bazel run well in Travis. I
will send a follow up PR for doing this.
@neuromage
Copy link
Contributor Author

/assign @IronPan
/cc @vicaire
/cc @Ark-kun

@@ -365,19 +365,26 @@ func (s *RunStore) UpdateRun(runID string, condition string, workflowRuntimeMani
// new in the status of an Argo manifest. This means we need to keep track
// manually here on what the previously updated state of the run is, to ensure
// we do not add duplicate metadata. Hence the locking below.
row := tx.QueryRow("SELECT WorkflowRuntimeManifest FROM run_details WHERE UUID = ? FOR UPDATE", runID)
var query string
Copy link
Contributor

Choose a reason for hiding this comment

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

Could we have an interface that abstracts away the differences between the MySQL and SQLLite DB? I think it would look cleaner than having switch statements.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The difference in behaviour is real and not abstract, and in the interest of code readability, it's worth making this explicit. This makes it clear to the reader that with mysql, we do a row lock, while no such locking takes place with sqlite. That's a fundamental difference that I think is worth highlighting to the reader, rather than hide it behind some abstraction. It's crystal clear here that row locking path is never tested in unit tests as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I moved this to the db interface, FWIW. PTAL.

}

if s.metadataStore != nil {
Copy link
Contributor

Choose a reason for hiding this comment

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

Could we use the null design pattern here so that we don't forget to perform this check? (i.e. we have an interface with an actual implementation calling MySQL, and actual implementation calling SQLLite, and a "NullImplementation" that does not do anything.

This pattern really helps keep the code concise and easy to read by leveraging OO instead of requiring if/then/switch statement in several places.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I removed the comparison to nil because I now expect s.metadataStore to always be non-nil, unlike before, when it was nil in tests.

Go is not an OO language, and I don't think it's a good practice to shoehorn OO design patterns in Go code.

@vicaire
Copy link
Contributor

vicaire commented Mar 21, 2019

/lgtm
/approve

@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: vicaire

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

1 similar comment
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: vicaire

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@Ark-kun
Copy link
Contributor

Ark-kun commented Mar 21, 2019

/test kubeflow-pipeline-e2e-test

@k8s-ci-robot k8s-ci-robot merged commit 02de9c5 into kubeflow:master Mar 21, 2019
Linchin pushed a commit to Linchin/pipelines that referenced this pull request Apr 11, 2023
magdalenakuhn17 pushed a commit to magdalenakuhn17/pipelines that referenced this pull request Oct 22, 2023
additionally remove some inactive reviewers
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants