馃悰 bug report
The current implementation of the function tamr_client.project.by_name uses a the GET /v1/projects with a filter on the "name" property. In the filter this name is the internal name of the project and not the name displayed in the UI (the displayName. Confusingly, the returned project JSON object has a "name" property that is the displayName.
馃槸 Current Behavior
For example, if a project was created with the name "project_name" and then renamed to "project_display_name":
- A call of
tc.project.by_name(session, instance, "project_display_name") or equivalently GET /v1/projects?filter=name==project_display_name will return nothing.
- A call of
tc.project.by_name(session, instance, "project_name") or equivalently GET /v1/projects?filter=name==project_name will return a project JSON with the property "name": "project_display_name".
馃 Expected Behavior
There should be a way of getting a project by its displayName since this (and to a lesser extent resourceId) is the only thing identifying a project in the UI.
馃拋 Possible Solution
This is a manifestation of the design of the versioned API design and the issue could be fixed there, however a possible workaround in tamr_client is:
The current implementation of by_name which actually retrieves a project by the internal "name" could be changed to a hidden/power-user function _by_name and a new by_name function could be defined that streams all projects and returns the one that matches on displayName ("name" in the returned JSON).
馃悰 bug report
The current implementation of the function
tamr_client.project.by_nameuses a theGET /v1/projectswith a filter on the "name" property. In the filter this name is the internal name of the project and not the name displayed in the UI (thedisplayName. Confusingly, the returned project JSON object has a "name" property that is thedisplayName.馃槸 Current Behavior
For example, if a project was created with the name "project_name" and then renamed to "project_display_name":
tc.project.by_name(session, instance, "project_display_name")or equivalentlyGET /v1/projects?filter=name==project_display_namewill return nothing.tc.project.by_name(session, instance, "project_name")or equivalentlyGET /v1/projects?filter=name==project_namewill return a project JSON with the property "name": "project_display_name".馃 Expected Behavior
There should be a way of getting a project by its
displayNamesince this (and to a lesser extentresourceId) is the only thing identifying a project in the UI.馃拋 Possible Solution
This is a manifestation of the design of the versioned API design and the issue could be fixed there, however a possible workaround in
tamr_clientis:The current implementation of
by_namewhich actually retrieves a project by the internal "name" could be changed to a hidden/power-user function_by_nameand a newby_namefunction could be defined that streams all projects and returns the one that matches ondisplayName("name" in the returned JSON).