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
@clingerman: I thought about/looked into this, but I don't think it is logically possible with the way the catalog is set up. Since the record groups don't contain the series-level metadata, we'd have to search all RGs, collections, and series as well, even though we are only doing this to find the RGs/collections with matches in their child series. What this means is every series result would essentially just represent a hit for its RG/collection, but then there could be many hits in the series-level records for the same RG/collection.
So, rather than searching a small set (few hundred records) of unique records as it does currently, we are searching a set of hundreds of thousands of records, and we'd have to scan through the entire set each time to extract the record group numbers/collection IDs for every result and then de-duplicate the list to generate the results on the GFR's end. If you search for a common term like "army", you'll get 58,000+ results at the series level, which makes that workflow basically impossible. Even if we weren't limited by pagination, it would take a very long time to load all of those results to generate the GFR search result set from them.
Add series as a data source for the results pulled back in a keyword search.
The text was updated successfully, but these errors were encountered: