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

[WIP] Some cleanups #790

Merged
merged 6 commits into from
Jan 4, 2019
Merged

[WIP] Some cleanups #790

merged 6 commits into from
Jan 4, 2019

Conversation

mparkhe
Copy link
Collaborator

@mparkhe mparkhe commented Jan 3, 2019

Getting some conformity with usage for RunStatus and source. Some paths were using strings while others were using the enum values.

  • More testing with local MySQL backend
  • Additional conformity between FileStore and SqlAlchemyStore (statuses and sources)
  • Using constants from entities

@@ -208,7 +208,7 @@ def set_terminated(self, run_id, status=None, end_time=None):
Defaults to "FINISHED".
:param end_time: If not provided, defaults to the current time."""
end_time = end_time if end_time else int(time.time() * 1000)
status = status if status else "FINISHED"
status = status if status else RunStatus.to_string(RunStatus.FINISHED)
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

flipping existing usage of free flowing strings to pre-defined constants. ^^this^^ is one example. More further down..

@@ -150,7 +150,7 @@ def start_run(run_uuid=None, experiment_id=None, source_name=None, source_versio
return _active_run_stack[-1]


def end_run(status="FINISHED"):
def end_run(status=RunStatus.to_string(RunStatus.FINISHED)):
Copy link
Contributor

Choose a reason for hiding this comment

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

n00b questions for you: is the goal to have functions take in the enum and not the string? seems true for create_run above but not for this one (end_run). or these functions are meant for different contexts so we want the enum for one and the string for the other ?

Copy link
Collaborator Author

@mparkhe mparkhe Jan 4, 2019

Choose a reason for hiding this comment

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

No! that is a good observation. This PR matches the behavior of SqlAlchemyStore's API with that of FileStore since the caller for them are the same client/fluent depending on the context and they will instantiate the backend store. That said, it does make sense to take audit of these APIs and maintain constancy and see if some of these APIs need to be changed (it could result in a breaking API change)

My preference is enums -- and use strings for readability -- logs, messages, UI ... etc.

Copy link
Contributor

Choose a reason for hiding this comment

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

but we do want this end_run function to take in a string because it's exposed to the end user, right? (so this PR is good to go?) and eventually we want all the internal methods to take in the enum.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yeah. I agree that user facing functions to take in string-y fields and we can check for valid values.

This change only replaces the default value of status from constant "FINISHED" to RunStatus.to_string(RunStatus.FINISHED) <-- still a string argument.

@sueann
Copy link
Contributor

sueann commented Jan 4, 2019 via email

@sueann sueann added the LGTM label Jan 4, 2019
- runs.source_version column increased size to 50
- runs.name: column removed uniqueness constraint, defaults to "" (in entities.run_info) if not provided
- missing default system tags to match FileStore
@mparkhe mparkhe merged commit ddc0013 into mlflow:master Jan 4, 2019
@mparkhe mparkhe deleted the search_fix branch July 2, 2019 16:44
@mparkhe mparkhe restored the search_fix branch July 2, 2019 16:44
@mparkhe mparkhe deleted the search_fix branch July 8, 2020 04:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants