[Koha-bugs] [Bug 27842] Incorrect biblionumber handling in serials subscriptions

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27842

--- Comment #19 from Katrin Fischer <katrin.fischer at 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.