Date
13
Attendees
@Dwayne Swigert
Theodor Tolstoy (One-Group.se)
Ann-Marie Breaux (Deactivated)
Goals
Discussion items
| Time | Item | Who | Notes | No meeting | Topics for next week | ||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Issues with Search | Kelly | Kelly - A lot of fields are not indexed. For ex, trying to match on an 856 to search for duplicates - this crashed the system. Only tried to load 5,000 records but couldn't. Talked with Zak and he confirmed that this will keep happening, at least with Inventory. There is resistance to adding more indexes because that bulks up the system. Part of this is due to how the indexes are set up, we're not sure how SRS is set up. Charlotte - need a list of search indexes of those that are indexed already and figure out which ones are clearly missing. We are still looking into elastic search so are in an in-between moment. How do we decide where to put our efforts? Patty - can you put these extra indexes in your own tenant in the short term? Yes, it is possible but is not a long-term solution. Tod - long term solution seems to be putting elastic search into place but we don't know when that's coming, some work is tentatively planned for Iris. Need a solution for the next year. Brooks - hasn't needed to test this yet. Kelly - what about Marc Johnson's Slack comment that elastic search won't fix this problem? Tod - will have to look deeper. To use the results of elastic search for updating wouldn't work, shouldn't trust this, need to go back to source. We'll have to separate search and updates. Tod - had a problem in OLE where results of a loan search, for ex, where the information in the results were slightly out of date. Kelly - Lehigh is using LDP for matching, pulling out identifiers and loading those. Possibility for this to work but seems like a lot of work. Patty - what number triggers the crash? Answer - It depends on the size of the database AMB - search indexes have to be in a particular app, correct? Incoming records trying to match 856 against inventory? In bug fest there is a test for this but doesn't know the size of the test file. Q - can we make sure that this is tested well in bugfest? Kelly is writing a test case. AMB -the way the source records are stored now is a problem . Tod - Chicago has experience with breaking up MARC to make is more index-able. AMB - not sure what effect changing the way it's stored would have on other function. Theodor - loading records already takes a lot of time, adding more indexes could slow things down even more. Kelly - it sounds like we're on our own short term - will the others be comfortable going live next summer winging it, or should there be a plan? - Tod wants to see what comes out of Iris planning (Nov 12) AMB - In case it's useful, here's some SRS changes proposed by Texas A&M, which we'll be considering in R1 - see individual stories linked to this Feature:
| |||||||||
| Optimistic locking | Debra | UXPROD-1752 AMB - Jakub has been having meetings Debra - they posted on Slack that they want to have a community forum but nothing has happened See also
| |||||||||
| MARCCat | Tom | Also need a real plan for MARCCat, it's never clear where it is Kelly - new strategic plan states that we'll have X number of libraries fully functional, here are some things we know we have to address soon Tom - would like to see the implemented and soon-to-implement libraries to get together to give demos and find where the problems are, how to figure out a workaround now. AMB - this is going on in several of the SIGs. Others - yes, but it still might be helpful to have some of this in Implementers | |||||||||
| Topics for next week | Cate Boerema from Capacity Planning Team will talk with us about bugs reported for features that aren't developed yet. Have a walk through of an area on Nov 10? It will have to be constrained, "acquisitions" would be too big |