feat(instance-search): create computed field for sorting and filtering Date1

[SvitlanaKovalova1]

Purpose

MSEARCH-806 Currently in the Instance schema, there is a field for publication date. However, this data originates from an uncontrolled string in variable fields of the MARC record. The dates in the 008 are more consistently formatted, and are more useful for certain materials like serials. Previously, we implemented sortable properties (publicationPeriod.start/publicationPeriod.end) that are parsed from the publication date field. We need to break this relationship, and instead make the source of that data the 07-14 from the 008. The 008 structure allows for a single position to indicate the type of date that will be represented in the following positions.
008/06 = Date type
008/07-10 = Date 1
008/11-14 = Date 2

For this story, we need to create computed fields from Date 1 for sorting and filtering dates. And we need validation on the backend that stores those validation rules, and if the values in Date 1 don’t pass validation, we should consider as zeroes so that they still show in results list and show in filters

Requirements:

• If Date 1 contains “u” in one of the four characters, replace “u” with 0
• If no data, consider as 0
• Store validation rules for Date 1:
  - Each can only store up to four characters
  - Allows for numeric values and the alpha “u”
• If characters in Date 1 do not pass this validation, consider the values as 0
• Return Date 1, Date 2, and Date type
• Verify the ability to search original data (not computed field) in “All” search; example queries:
  - Support trailing, leading, and internal wildcards and exact matches (15*, 02, 197, 1970)
  - Dates with “u” should follow the original data (not the computed field with “u” replaced with “0”): 199u exact match, would also match “199*”

Approach

Update index:

1. Add new Instance schema fields: dateTypeId, date 1, date 2. It is searchable based on requirements.
2. Add a new searchable field: sort_date1. It is computed from date 1 based on requirements. It works with range queries and is used for sorting.

Changes Checklist

• API Changes: Document any API paths, methods, request or response bodies changed, added, or removed.
• Database Schema Changes: Indicate any database schema changes and their impact. Confirm that migration scripts were created.
• Interface Version Changes: Indicate any changes to interface versions.
• Interface Dependencies: Document added or removed dependencies.
• Permissions: Document any changes to permissions.
• Logging: Confirm that logging is appropriately handled.
• Unit Testing: Confirm that changed classes were covered by unit tests.
• Integration Testing: Confirm that changed logic was covered by integration tests.
• Manual Testing: Confirm that changes were tested on local or dev environment.
• NEWS: Confirm that the NEWS file is updated with relevant information about the changes made in this pull request.

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
94.1% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[psmagin]

Good job!