tensorflow / tensorflow/tensorboard
Merge `data_location` into `experiment_metadata`
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 7.2k
- Forks
- 1.7k
- Avg merge
- 4d 22h
- Merged PRs (30d)
- 1
Description
The data location field is a piece of metadata scoped to an experiment,
so one would expect it to be returned by experiment_metadata. But it
is not so: data_location is a separate call. This forces two separate
database queries, which is unnecessary since core_plugin calls them
consecutively at the unique call site. Thus, it’s more than just a
cleanliness issue.
Suggest migrating by first making ExperimentMetadata more malleable:
- Make
ExperimentMetadata.__init__take kwargs only, and provide
default values for all fields/arguments. - Update data providers to always return a non-
Nonevalue.
While this loses the ability to distinguish whether the metadata is
present, we already weren’t able to distinguish between whether
individual fields were present. For instance, TensorBoard.dev
experiments that were created prior to the introduction of experiment
names and descriptions still returned metadata with creation time
but with experiment_name="".
Then:
- Add a new
data_locationfield with default value"". - Update data providers to populate the new field, and update
core_pluginto prefer that field if populated. - Remove the
data_locationmethod. - Remove dead
data_locationimplementations from data providers.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at the linked call site in core_plugin.py, then trace ExperimentMetadata and the data provider implementations, including their data_location methods. Confirm how the two consecutive calls are used and update the affected providers and consumers. Done means data_location is available through experiment_metadata and the separate method and dead implementations are removed.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100