Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for addition of arbitrary metadata to DAISY entities #294

Closed
pinarpink opened this issue Sep 24, 2021 · 2 comments · Fixed by #295
Closed

Add support for addition of arbitrary metadata to DAISY entities #294

pinarpink opened this issue Sep 24, 2021 · 2 comments · Fixed by #295
Labels
blocker The issue is of most importance discuss This issue requires discussion enhancement New feature or request
Milestone

Comments

@pinarpink
Copy link
Member

We need to be able to add arbitrary metadata to DAISY entitiies (Project, Study/Cohort, Dataset).

This functionality is initially needed to be able to associate scientific metadata with DAISY datasets. For this case the metadata will be a JSON BLOB.

Assignee needs to discuss options with the End2End team before embarking on the implementation. typed/untyped metadata, K-V pairs, so on.

@pinarpink pinarpink added enhancement New feature or request discuss This issue requires discussion blocker The issue is of most importance labels Sep 24, 2021
@jLebioda
Copy link
Collaborator

jLebioda commented Oct 1, 2021

The ways I can see to implement #294:

  • add a TextField to CoreTrackedModel (parent class of Project/Dataset/Cohort/Partner) to store the complete collection of key-values as raw string. A disadvantage is that we must ensure that it contains a valid JSON, but it’s a bit more flexible.
  • add a JSONField to CoreTrackedModel to store the complete collection of key-values as JSONb. Slightly less flexible (Postgresql-specific, and will always need a valid JSON), but offers validation on DB level. Slightly slower to write (converts text to some binary blob/probably negligible overhead), but more efficient in storing the data.
  • add M2M key-value relationships (a single entry for every Object-Key-Value tuple - will probably be most efficient and flexible in terms of what it offers, but way harder to maintain compared to the other two.

I will implement the first option if there are no comments/objections

@vildead vildead added this to the 2021-10 milestone Oct 19, 2021
@vildead vildead linked a pull request Oct 19, 2021 that will close this issue
@jLebioda
Copy link
Collaborator

Closing this one, further upgrades will be conducted in #300 and #302

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocker The issue is of most importance discuss This issue requires discussion enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants