https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27842
--- Comment #19 from Katrin Fischer <[email protected]> --- (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. _______________________________________________ Koha-bugs mailing list [email protected] https://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/
