https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15108
--- Comment #35 from Frédéric Demians <frede...@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. _______________________________________________ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/