search

Datatamer / tamr-client

Programmatically interact with Tamr
https://tamr-client.readthedocs.io
Apache License 2.0
11 stars 25 forks source link

TC: Enrichment type project breaks `tc.project.get_all` #480

Closed tiems90 closed 3 years ago

tiems90 commented 3 years ago

🐛 bug report

When running tc.project.get_all() on an instance that has an enrichment type project, throws an error.

🤔 Expected Behavior

No error.

😯 Current Behavior

---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-4-d0195f5110c8> in <module>
----> 1 projects = tc.project.get_all(**conf)

~/.pyenv/versions/3.8.6/envs/3.8/lib/python3.8/site-packages/tamr_client/project.py in get_all(session, instance, filter)
    194     for project_json in projects_json:
    195         project_url = URL(instance=instance, path=project_json["relativeId"])
--> 196         project = _from_json(project_url, project_json)
    197         projects.append(project)
    198     return tuple(projects)

~/.pyenv/versions/3.8.6/envs/3.8/lib/python3.8/site-packages/tamr_client/project.py in _from_json(url, data)
    111         return golden_records_project._from_json(url, data)
    112     else:
--> 113         raise ValueError(f"Unrecognized project type '{proj_type}' in {repr(data)}")
    114 
    115 

ValueError: Unrecognized project type 'ENRICHMENT' in {'id': 'unify://unified-data/v1/projects/31', 'name': 'Country Code Standardiser', 'description': '', 'type': 'ENRICHMENT', 'unifiedDatasetName': '', 'created': {'username': 'admin', 'time': '2020-11-24T17:19:17.821Z', 'version': '22756'}, 'lastModified': {'username': 'admin', 'time': '2020-11-24T17:20:38.817Z', 'version': '22779'}, 'relativeId': 'projects/31', 'externalId': '97b543d5-23f4-4341-8108-cbbd476b6bc6'}

💁 Possible Solution

Add the additional project type.

🌍 Your Environment

Software Version(s)
tamr-unify-client 1.0.0
Tamr server 2020.01.0
Python 3.8.6
Operating System MacOS
skalish commented 3 years ago

@pcattori Is there any reason we should not add EnrichmentProject to TC at this time?

pcattori commented 3 years ago

There are three (not necessarily mutually exclusive) options we have:

I'm not familiar with Enrichment projects and how they differ from the other project types, so it's unclear to me if its compatible with our existing functionality.

If someone understands/can explain Enrichment projects, we'll be better equipped to choose from the above options.

skalish commented 3 years ago

My understanding right now is that Enrichment projects are modules (like GR "projects") have a UI implementation but are behind a feature flag in the UI. They can be interacted with via the versioned APIs GET /v1/projects, GET /v1/projects/{projectId}, and GET /v1/projects/{projectId}/inputDatasets, and can't be created or modified with any existing versioned APIs. As a result, (a) and (b) are the same (there is no specific functionality for Enrichment projects).

I think option (c) is the best choice for now. This will future-proof us against any other added module/project types that might show up in experimental or demo instances, and also indicates that Enrichment projects are not really a supported use case yet. As soon as that last point changes, adding an EnrichmentProject makes more sense.

pcattori commented 3 years ago

Yes, seems like Enrichment is still in Alpha. So we shouldn't try to represent Enrichment project types yet.

Let's go with UnknownProject.

github-actions[bot] commented 3 years ago

:tada: This issue has been resolved in version 1.1.0 :tada:

The release is available on:

Your semantic-release bot :package::rocket: