https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27842 --- Comment #19 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Nick Clemens from comment #18)
(In reply to Katrin Fischer from comment #17)
The data loss angle is the one I am worried about as well. With the solution proposed here we lose the former history. That's why I was thinking we might want to check on why the field was there in the first place.
Should we just have a patch undoing the constraint for now?
I don't think we are losing anything by setting the biblionumber to the current.
In the case of a serial having had 2,3, or more biblionumbers, we are only using the first one - so while one previous connection was "preserved" any future ones were not. Even with one change preserved I don't see any evidence that it was intentional
Can you explain about only using the first one? As I read it we are updating all of them: UPDATE serial JOIN subscription USING (subcriptionid) SET serial.biblionumber = subscription.biblionumber WHERE serial.biblionumber != subscription.biblionumber Why not just update the receive process to use the subscription for pulling the biblionumber and change the constraint to set null on delete? -- You are receiving this mail because: You are watching all bug changes.