We'd like to propose enhancing the getCollectionItems use case to expose more of the /api/search API’s dataset search functionality while preserving the existing API behavior.
What do you think of the suggested points below? We're open to providing a PR for these changes.
Collection information
Add a showCollections option to the use case. When enabled, the /search request should include show_collections=true. Dataset results should then expose their associated collections, transformed into the existing CollectionSummary type.
Metadata fields
Add support for a metadataFields option accepting multiple field specifications in the format:
metadataBlockName:fieldName
(as defined in the Dataverse Search API documentation)
Each value should be sent as a separate metadata_fields query parameter. When metadata fields are returned, transform the metadataBlocks payload using the existing dataset metadata transformer.
Also add a keepRawFields option so callers can choose whether metadata values remain unchanged or are transformed to Markdown.
Complex filter queries
Remove the restriction that filter queries must follow a simple key:value format. Filter queries should also accept arbitrary strings, including:
- Parentheses
- Mixed AND and OR operators
- Wildcards, such as
abc:* or subtreePath:*/42
- Numerical or date ranges, such as
abc:[0 TO 100]
- Already-quoted values, such as abc:"xyz"
Complex expressions should be forwarded unchanged. Simple filters can continue using the existing normalization behavior, provided query strings like the ones listed above are not incorrectly wrapped in quotes.
Since Solr syntax is broad and allows more special operators (e.g., boosting, fuzziness, regex) than what I listed above, implementing a detection function that determines whether to transform the filter query or not may be quite complex and brittle.
I think it might be cleaner to just allow the user to specify if the filter query should be passed through without transformation, either via boolean flag param or by changing the type from string[] to string | string[], allowing users to pass an already complete and "finished" query string instead of a string array of individual filters.
We'd like to propose enhancing the
getCollectionItemsuse case to expose more of the/api/searchAPI’s dataset search functionality while preserving the existing API behavior.What do you think of the suggested points below? We're open to providing a PR for these changes.
Collection information
Add a
showCollectionsoption to the use case. When enabled, the /search request should includeshow_collections=true. Dataset results should then expose their associated collections, transformed into the existingCollectionSummarytype.Metadata fields
Add support for a
metadataFieldsoption accepting multiple field specifications in the format:metadataBlockName:fieldName(as defined in the Dataverse Search API documentation)
Each value should be sent as a separate
metadata_fieldsquery parameter. When metadata fields are returned, transform the metadataBlocks payload using the existing dataset metadata transformer.Also add a
keepRawFieldsoption so callers can choose whether metadata values remain unchanged or are transformed to Markdown.Complex filter queries
Remove the restriction that filter queries must follow a simple
key:valueformat. Filter queries should also accept arbitrary strings, including:abc:*orsubtreePath:*/42abc:[0 TO 100]Complex expressions should be forwarded unchanged. Simple filters can continue using the existing normalization behavior, provided query strings like the ones listed above are not incorrectly wrapped in quotes.
Since Solr syntax is broad and allows more special operators (e.g., boosting, fuzziness, regex) than what I listed above, implementing a detection function that determines whether to transform the filter query or not may be quite complex and brittle.
I think it might be cleaner to just allow the user to specify if the filter query should be passed through without transformation, either via boolean flag param or by changing the type from
string[]tostring | string[], allowing users to pass an already complete and "finished" query string instead of a string array of individual filters.