[Koha-bugs] [Bug 34782] ImportBreedingAuth does not limit to the import batch

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34782

--- Comment #2 from Phil Ringnalda <phil at chetcolibrary.org> ---
I'm not sure how many of these are readily fixable in a single reworking, but
there are several other problems (unsurprisingly, since we're using it as a
cache, and cache invalidation is canonically a hard problem):

Even using the import batch just means limiting by the hostname of the server.
For the two we ship, there aren't collisions because control numbers in the LC
NAF start with n and control numbers in the LC SAF start with sh (or sj or gf),
but there's no guarantee that holds true for any domain name hosting more than
one authority database. You could easily get baffling errors when
auths-o-plenty.com happened to have two records with the control number
0001372638648 with the same 100 and everything else different, from two
different databases so as far as they were concerned there was no collision.

There's also nothing in MARC saying that 001 is unique within a single
database. (003)001 really ought to be since they are completely meaningless
otherwise, but not 001.

Nor does (003)001+1xx define a particular instance of the record: when someone
dies and gets the year of their death added to their personal name record, it
will also be added to their name in a 500 see-also in the corporate name record
for the name of the band they were a member of. If you look for the records on
the day that your source is changing them, but an hour before they actually
did, you'll be fine for the personal name, since we'll be looking for
Timberlake, Justin, 1981-2023 and not confused by Timberlake, Justin, 1981-,
but once you looked at the copy of 'NSync (Musical Group) with 500 Timberlake,
Justin, 1981-, that's all you will be shown, making you think your source was
sloppy and failed to update the see-also. I've actually done that, and wondered
what sort of workflow caused the LC to update the main entry a day before they
updated the see-also, because by the next day I had a cleaned-up lx2.loc.gov
that no longer had an outdated cached copy.

-- 
You are receiving this mail because:
You are watching all bug changes.
You are the assignee for the bug.