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

complex/component fields #1083

Open
kosarko opened this issue Nov 14, 2023 · 4 comments
Open

complex/component fields #1083

kosarko opened this issue Nov 14, 2023 · 4 comments

Comments

@kosarko
Copy link
Member

kosarko commented Nov 14, 2023

view:
Image

vs

Image

What about indexing? There used to be some special treatment in:

<dynamicField name="*_comp" type="componentFilter" indexed="true" stored="false" multiValued="true" omitNorms="true" />

and

https://github.com/ufal/clarin-dspace/blame/8a6ba5c98547942d7115b74cf4978e0b29ca50e4/dspace-api/src/main/java/cz/cuni/mff/ufal/dspace/discovery/SolrServiceTweaksPlugin.java#L241

@milanmajchrak
Copy link
Collaborator

Please, where is used some value from field + "_comp"? I see it is indexed, but I cannot find where it is used except of this https://github.com/ufal/clarin-dspace/blob/clarin/dspace/solr/search/conf/schema.xml#L679

Another question: I see you have changed copyField values, should it be updated in the v7? V7 looks like this: https://github.com/dataquest-dev/DSpace/blob/dtq-dev/dspace/solr/search/conf/schema.xml#L362

@kosarko
Copy link
Member Author

kosarko commented Apr 30, 2024

Please, where is used some value from field + "_comp"? I see it is indexed, but I cannot find where it is used except of this https://github.com/ufal/clarin-dspace/blob/clarin/dspace/solr/search/conf/schema.xml#L679

@milanmajchrak I think (https://github.com/ufal/lindat-repository-obsolete/pull/97/files, https://github.com/ufal/lindat-repository-obsolete/pull/99/files) this is there mostly for the full text search and autocompletes (those are the copy fields);

Not sure what the intention with the analysis was. It is used in:

required="true" autocomplete="solr-local.size.info_comp"/>
(autocomplete); and you can use them directly in search and they provide slightly different results: https://lindat.mff.cuni.cz/repository/xmlui/discover?query=local.sponsor_comp%3AeuFunds vs https://lindat.mff.cuni.cz/repository/xmlui/discover?query=local.sponsor%3AeuFunds

Another question: I see you have changed copyField values, should it be updated in the v7? V7 looks like this: https://github.com/dataquest-dev/DSpace/blob/dtq-dev/dspace/solr/search/conf/schema.xml#L362

I can see two reasons for this (but really am guessing):

  1. someone wanted to influence the relevancy/order of results
  2. we did have all the bitstream previews in local metadata (with no limits) and * would copy that; search_text would be huge...

@kosarko
Copy link
Member Author

kosarko commented Apr 30, 2024

On the topic of complex fields...I don't think the required flag behaves as it should; the requirements are not enforced if the whole field is not mandatory (it seems).

Funding is an optional field, but if someone decides to fill it in, they should succeed only if they fill in all the inputs marked as required.
Or with size info...you need both the number and the unit and that's independent on whether local.size.info is mandatory or not.

@kosarko
Copy link
Member Author

kosarko commented Oct 10, 2024

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants