You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
We want to reference Article from a DataSet, article being a normal record containing "metadata" section. With PIDRelation("metadata.article", keys=["metadata.title"], pid_field=...) the included metadata in the DataSet look like:
In most cases, a more concise representation without the "metadata" section would look better (the same serialization we have for referenced vocabularies):
To achieve that, one can extend the RelationResult class and change the _dereference_one method - but that means copy/paste of Invenio code.
Describe the solution you'd like
Change dict_lookup, dict_set functions to methods on RelationResult class. Then in the use case above one would just override them.
Describe alternatives you've considered
An alternative for the usecase above would be to have the "keys" field not a list of fields, but a map from source_path to destination_path. This is not backward compatible and has more limited use than the solution above.
Is your feature request related to a problem? Please describe.
We want to reference Article from a DataSet, article being a normal record containing "metadata" section. With
PIDRelation("metadata.article", keys=["metadata.title"], pid_field=...)
the included metadata in the DataSet look like:In most cases, a more concise representation without the "metadata" section would look better (the same serialization we have for referenced vocabularies):
To achieve that, one can extend the
RelationResult
class and change the_dereference_one
method - but that means copy/paste of Invenio code.Describe the solution you'd like
Change
dict_lookup
,dict_set
functions to methods onRelationResult
class. Then in the use case above one would just override them.Describe alternatives you've considered
An alternative for the usecase above would be to have the "keys" field not a list of fields, but a map from source_path to destination_path. This is not backward compatible and has more limited use than the solution above.
A workaround can be:
but is looks more like a kind of hack (changing generated representation).
The text was updated successfully, but these errors were encountered: