Hi, For this specific project, I personally don't have control of anything per se, but the sponsors of the code will have control of their Koha instance and theoretically the data in the upstream data provider - although not control of the data provider itself.
I have thought a bit about policy, but I'm not sure that it's entirely relevant in this case. Regardless of ownership, you can't really do a cascade delete if a bib's items are on loan or on hold or otherwise engaged. For example, let's say that the upstream data provider was the sole provider of bib and item data into Koha. If they delete the record upstream but an item is engaged downstream, the delete will fail. I suppose in my particular case it might not matter too much... as the library might not delete their records from upstream until the items have been dealt with downstream. But I doubt that would be the case for all users and it doesn't account for user mistakes either. You could still end up with orphaned records in Koha that no one necessarily knows to remove. As for the scenario where the Koha user can add items to harvested bibs, which may be the case for the sponsors, that is indeed more complicated. On one hand, the upstream data provider provides all the bibliographic data so they "own" the record. On the other hand, does the upstream data provider have knowledge of the downstream items? They might or they might not... I think perhaps I'm beginning to understand your point. Due to the variety of scenarios, perhaps it makes sense to track all OAI-PMH transactions, and then have policies for controlling how deletions are processed from there. That way, even if direct deletions are the norm, errors for failed deletions can be tracked. Or if users would prefer to know that an upstream bib has been deleted but they want to keep their downstream bib, that can be an option too. Those options can also be fleshed out over time as needed in terms of a dashboard, alerting, etc. Tracking the transactions in the database would help me prevent some race conditions for asynchronous importing as well... Hmm, yes, I can see the sense of preventing that spill over beyond the OAI-PMH import domain. I think perhaps my original proposal was trying to cut too many corners. I'm tempted to amend the Bugzilla patch to include a system preference, but I suspect that I won't end up using this in my project anymore. Thanks for your feedback, Galen. It's much appreciated. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 > -----Original Message----- > From: Galen Charlton [mailto:[email protected]] > Sent: Saturday, 16 January 2016 2:36 AM > To: David Cook <[email protected]> > Cc: Koha Devel <[email protected]> > Subject: Re: [Koha-devel] Hide records on Leader 05 = d in OPAC > > Hi, > > On Fri, Jan 15, 2016 at 12:46 AM, David Cook <[email protected]> > wrote: > > I like the idea of just deleting records directly, but I think it's > > more complex than it appears at first glance. It's not just an issue > > with OAI-PMH either really. It's an issue any time you try to delete a > > record without providing feedback to an end-user. > > I've got a question for you: for the specific project you're coding for, which > ends do you control? The Koha instance, the data provider publishing via > OAI-PMH, or both? > > To make a general point: yep, there are definitely edge cases and error > conditions to consider when implementing a mechanism by which a third > party can specify that records should be deleted in a Koha database. Some of > those might be better solved by policy rather than code; for example, if the > OAI-PMH provider in some sense "owns" the records that Koha ingests from > it, does the Koha library need to a have policy of not adding items to such > records? If so, it might be appropriate to add an option that specifies that > bib > deletions are to forcibly cascade. > > Conversely, if it *is* legitimate for the Koha user to add items to those > records, does that mean that the OAI-PMH provider no longer has > "ownership"? > > To make another general point: I think it would be better for the > consequences of record deletion to be handled *within the context of OAI- > PMH harvesting* (or more generally, mechanisms to sync records with an > external provider), but *not* to have those consequences spill over for > users who are not doing such harvesting as all. Your original proposal to > unconditionally hide Leader/05='d' records from the public catalog would be > an example of such spillover. > > Regards, > > Galen > -- > Galen Charlton > Infrastructure and Added Services Manager Equinox Software, Inc. / The > Open Source Experts > email: [email protected] > direct: +1 770-709-5581 > cell: +1 404-984-4366 > skype: gmcharlt > web: http://www.esilibrary.com/ > Supporting Koha and Evergreen: http://koha-community.org & > http://evergreen-ils.org _______________________________________________ Koha-devel mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
