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

Index dates for Ephemera Folders #134

Open
2 tasks
tpendragon opened this issue Oct 1, 2024 · 3 comments · May be fixed by #138
Open
2 tasks

Index dates for Ephemera Folders #134

tpendragon opened this issue Oct 1, 2024 · 3 comments · May be fixed by #138
Assignees

Comments

@tpendragon
Copy link
Contributor

tpendragon commented Oct 1, 2024

Acceptance Criteria

  • There's a years field in the solr document that has all of the years in an array that should match.
  • There's a display_date field in the solr document that is what will render in the record page.

Implementation Note

The suffix isn't defined above, part of the ticket is figuring out which suffixes are appropriate for each field.

suffixes to use:

  • display field should be string, display_date_ss
  • years field, used for sorting, searching, and faceting, should be integer, years_is.
@hackartisan
Copy link
Member

The implied implementation for the query side here is:

A single date provided as part of a keyword search would be able to match one of the dates in the years field.

A date range facet would be submitted to solr as a range query, see blacklight range limit for an example: https://github.com/projectblacklight/blacklight_range_limit/blob/7f7dc5eff77d6dc14537c6e917aa9858e0f0cd7d/lib/blacklight_range_limit/segment_calculation.rb#L31

@hackartisan
Copy link
Member

hackartisan commented Oct 15, 2024

It looks like you can now sort multivalued fields in solr:

In the case of primitive fields, or SortableTextFields, that are multiValued="true" the representative value used for each doc when sorting depends on the sort direction: The minimum value in each document is used for ascending (asc) sorting, while the maximal value in each document is used for descending (desc) sorting. This default behavior is equivalent to explicitly sorting using the 2 argument field() function: sort=field(name,min) asc and sort=field(name,max) desc

This means we don't need the oldest_year and newest_year fields; I'm moving the info about these that was initially in the description below in a strikethrough block.

We'll have to set DocValues on the integer field type we use, see:

Outdated specifications:

  • There's an oldest_year field in the solr document that is the oldest year in the range.
  • There's a newest_year field in the solr document that is the newest year in the range.

Record A: "1920 - 1960"
Record B: "1930 - 1945"

If we use the oldest date for oldest to newest, and the newest date for newest to oldest, we get this:

Sort date ascending: Record A, Record B
Sort date descending: Record A, Record B

@hackartisan hackartisan transferred this issue from pulibrary/figgy Oct 15, 2024
@hackartisan
Copy link
Member

There is validation on the date range in figgy, but there's nothing saying you can only have a date_created or a date range. there's some discussion of this on pulibrary/figgy#302 but it looks like further work got ice boxed.

I'm planning to use the date range if it's there, and if not use date created.

@hackartisan hackartisan linked a pull request Oct 16, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants