https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15108 --- Comment #35 from Frédéric Demians <frederic@tamil.fr> --- (In reply to Katrin Fischer from comment #32)

Hm, I think in some cases it would be nice to include updates on available - I wouldn't rule that out. Maybe the decision to take the item change into account could be configurable?

You're correct. IMO there are three cases: (1) I don't want to send item info to harvesters. The item info are not needed or are retrieved later using Koha webservices. This could be achieved with include_items=0. (2) I want to send all item info to harvester, ie descriptive info (branch, call number, etc.) and circulation info (due date). This could be achieved with include_items=1. With Ere patch, those info are resent to harvester each time an item record is modified, or if a new item is added to an existing biblio record. It wasn't the case until now, which is a bug from my perspective. (3) I want to send to harvester item info, but just 'descriptive' info. I want that because I don't need availability info for example, or because it will be retrieved later via webservices. With the OAI-PMH protocol, the availability can't be provided to third party tools (say VuFind) in real time: webservices are needed. But items.homebranch could be very useful in a metacatalog populated via harvesting. And in this case, real time is not a requirement. So this mixed mode could make sense for some. Especially to avoid bringing a Koha server to its knee. (In reply to Ere Maijala from comment #34)

That said, if you think there should be an option to control whether item timestamps are taken into account, I can add that. But you're right in that if you'd like to only ignore status changes caused by circulation actions, that's not possible without changes deeper in the system.

I suspect that such an option would just add confusion. For scenario (3) described above, a new patch should be needed. But I was just curious whether you was able to measure the number of OAI-PMH requests to Koha on a large catalog with a lot of circulation.

Additionally we need to take into account floating collections that would cause item's location to change on checkin. I'm really an outsider to Koha (mainly a VuFind developer), so I'm not sure how everything works in practice, so I apologize if what I say doesn't make sense or use the correct terminology.

Floating collections modify item records, and so timestamp field. So you UNION request will work. -- You are receiving this mail because: You are watching all bug changes.