https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27842 --- Comment #20 from Nick Clemens <nick@bywatersolutions.com> --- (In reply to Katrin Fischer from comment #19)
(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?
Sorry I meant, the serial biblionumber is always the same, i.e.: Create subscription on biblionumber 1 and recieve a serial, it uses biblionumber1 Edit subscription to use biblionumber 2 and receive a serial, it uses biblionumber 1 Edit subscription to use biblionumber 3 and receive a serial, it uses biblionumber on Edit subscription to use biblionumber 4...and so on We are not keeping a history of the biblionumber, but rather keeping only the original biblionumber I don't see that storing 'NULL' or one older biblionumber gains us much over storing the current bibloionumber -- You are receiving this mail because: You are watching all bug changes.