[Archivesspace_Users_Group] Sorting Top Containers by indicator inaccurate?
Wendler, Robin King
robin_wendler at harvard.edu
Tue Jan 7 15:59:02 EST 2020
Hi,
You may remember I previously asked about problems with sorting Top Containers search results by Indicator. A developer here identified the code that governs this sort. He describes it thus, lightly edited:
It seemed like they were sorting by length, but they're actually doing something to divide the set of results first into those with indicators that begin with numbers and those that do not. When it starts with a number, they select the starting numbers until they hit a letter or special character (like a -), add padding #'s to the beginning until it is 255 characters long, then do it AGAIN with the full value of the indicator, resulting in a 510 character string that looks like the below monster (example is using indicator "42a"):
#############################################################################################################################################################################################################################################################42############################################################################################################################################################################################################################################################42a
When the indicator does NOT start with a number, it still does the above, but instead of the first step (#'s + the number) it only adds #'s. So, for the indicator S015.25 you get a whole ton of #'s plus the indicator at the end:
######################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################S015.25
Then these really long strings are what the Indicator field is sorted by, which results in them being both sorted by length AND by whether they start with a letter or number (during a sort, # symbols are sorted before 0-9 numbers, so indicators that start with a non-number character always appear first).
This, for us, results in an ascending order like this, dropping out intermediate TCs that sort correctly. You can see why this is not desirable:
>12
M-1
AM-2
M-14
XL03
AM-10
PS-88-PS-100
WW-212-WW351
PS-101-PS-102
WW-495-WW-630
H MS c30.4. (Folio)
Cylindrical case, Roll #7
1-35
1-6 and 1-7
1 (Paige box)
2
2-1
Are you aware of any background or functional spec for the current Top Container Indicator sort?
Thank you for any thoughts on this,
Robin
Robin Wendler
Library Technology Services
Harvard University
90 Mt. Auburn St.
Cambridge, MA 02138
617-998-5457
r_wendler at harvard.edu
From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> On Behalf Of Wendler, Robin King
Sent: Friday, November 22, 2019 3:37 PM
To: archivesspace_users_group at lyralists.lyrasis.org
Subject: [Archivesspace_Users_Group] Sorting Top Containers by indicator inaccurate?
Hello,
In our installation of ASpace, sorting Top Containers by Indicator in a Manage Top Containers result set is inaccurate. There is a ticket in JIRA https://archivesspace.atlassian.net/browse/ANW-889<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_ANW-2D889&d=DwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=JKUSUWdXrLBGP_rNc_JtcJNO9wvGRzWSZ2uoZzcT59w&m=dxhmnTDQh9Jv3kcuwCKYew6_y5I8CF8hcwK3qc2ANFE&s=CYnmLODmupoEXtepgBbG1g3wYzUycDph6guTIHtnEXo&e=> (Default numerically sort Top Containers in "Manage Top Container" Resource results), which is not what we want. We want the alphanumeric sort to be accurate. For example, we see results supposedly sorted by indicator that contain a sequence like this:
Iowa 1
...
Iowa 9
Ohio 1
...
Ohio A
Iowa 10
..
Iowa 55
Texas 1
...
Texas 9
Kansas 1
...Etc.
I don't know if it's related, but the typeahead search for Top Container from within a Container Instance fails to find any matches for known containers most of the time, and produces flaky results when it does.
We are planning on tackling both of these during an upcoming batch of small container management enhancements, but it would help to know if we are trying to solve a known problem elsewhere in the community, or if it is something peculiar to our installation.
Have you experienced either of these problems, and if so, have you identified the potential culprit(s)?
Thanks for your thoughts,
Robin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20200107/206edba7/attachment.html>
More information about the Archivesspace_Users_Group
mailing list