Open skalish opened 4 years ago
To conform with the intended design of this package as an interface to the APIs, it is more appropriate that the core issue here be solved in the API rather than by tamr-client
. The workaround suggested under Possible Solution is better left as the recommended way to use the currently-available functionality to get a project by its display name.
🐛 bug report
The current implementation of the function
tamr_client.project.by_name
uses a theGET /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 (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_name
will return nothing.tc.project.by_name(session, instance, "project_name")
or equivalentlyGET /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 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_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 newby_name
function could be defined that streams all projects and returns the one that matches ondisplayName
("name" in the returned JSON).