[MRG] Make metadata editable from the frontend

[cheahuychou]

• Make every field including the nested ones editable except MODELDB_model_id
• Flatten the array, and attach the appropriate flatten key value pair to the leaf
• Hide MongoDB ids

[suhailshergill]

Would there be controls around this to prevent accidental edits (and / or restrict when edits can or cannot be made)?
Also, is version history of changes and edits preserved?

[mpvartak]

@suhailshergill we can certainly add some checks wrt edits. Did you have particular kinds of checks in mind?

We are currently not preserving a history of edits on the metadata, but we can look into logging that too, if this is an important use case.

[mpvartak]

Please remove before merging

[mpvartak]

@weienlee please take a look

[mpvartak]

Math.pow(2, 31) -- throws error otherwise

[mpvartak]

Tested it out, looks good overall!

Some things to fix:

• Let's add an explicit edit button to enable editing. The double-click can cause accidental edits
• In arrays, both keys and values seem to be editable but with nested dictionaries, only the values seem to be editable. is this expected? we should always have both editable or only one

[suhailshergill]

@mpvartak my thought process (excuse the verbosity):

• the projects and models have some notion of versions (be it in git or otherwise). as such it doesn't often make sense to speak of a model unless you also specify/quantify the version. models also have metadata associated with them, some of which is tracked/displayed in ModelDB. i hope nothing so far is controversial - if it is, then it's possible that i may be misunderstanding something.

• metadata cannot live in isolation. it should have a reference to the model/project code and since it doesn't make sense to talk about a model without specifying a version, the metadata should reference a particular version of the associated code.

• since metadata and the code it's referring to are coupled (with the latter being versioned), it makes sense for the metadata to be versioned as well. more importantly, if metadata isn't versioned then you introduce ambiguity.

• in a world where metadata and code both are versioned, it's important to identify:

  • the metadata alterations which can happen without any code changes (and why)
  • for metadata changes which can happen without any code changes
    • what are the invariants which must be respected?
    • how do we enforce said invariants?

specifically, one concrete potential invariant might be that any metadata change (similar to a code change) must be reviewed. if so, how would we enforce that?
without addressing the above(and related) scenarios, having a way to disable this feature would probably be useful. @arubisov , thoughts?

[cheahuychou]

@mpvartak Just addressed your comments, and added an edit button.

In arrays, both keys and values seem to be editable

Could you give an example? Only values should be editable.

[mpvartak]

Changes look good. Maybe have missed that before.

Two small fixes:

• Date created shouldn't be editable (we need to find a way to specify what fields are editable)
• When you update a value to be of a different type (e.g. num --> string), the server throws an error but this does not get piped to the frontend. Let's show an error message or something.

OK for this PR to not address metadata versioning; that can be a separate PR.

[mpvartak]

@suhailshergill Thanks for sharing your thoughts regarding metadata. Here's our thinking:

• Metadata is associated with a unique version of the model, so it doesn't exist by itself
• It makes sense that metadata changes should be versioned since the rest of the information is versioned too
• Currently however, a developer can make thrift calls directly or use the client to update metadata once a model record has been created (e.g. adding metrics once the model finishes training); i.e. it isn't limited to the frontend functionality. So a solution here will have to span all the update ops we can do on ModelDB.
• Since metadata versioning will impact all updates to ModelDB, we want to come up with a good way to version all metadata. We will explore this more and send around a GDoc w/the design soon.
• For now, we will add an option to make the metadata static

Let me know if you or Anton have other thoughts!

[suhailshergill]

@mpvartak looking forward to the gdoc with design options for metadata versioning

[mpvartak]

@suhailshergill Yes, on my list!