The functions C4::Serials::GetSubscription and C4::Serials::GetSubscriptionsFromBiblionumber return subscriptions where subscriptionid is undefined when the subscription have no subscription history. The database queries use wildcards to include fields from a left joined table. subscriptionhistory.subscriptionid will be NULL, which might be the value choosen as the field subscriptionid. How the field is chosen may depend on the version of DBI as this problem was discovered after an upgrade to Ubuntu Focal Fossa from Bionic Beaver.
Created attachment 118291 [details] [review] Bug 27964: Don't use wildcards for subscriptionhistory table in subscription queries
Hi Andreas, could you please include a test plan and problem description in your commit message? Should this be Needs Signoff?
Can confirm this for 20.11, have to retest on master still.
(In reply to Katrin Fischer from comment #2) > Hi Andreas, could you please include a test plan and problem description in > your commit message? Should this be Needs Signoff? Katrin's questions still await a response!
I think it is hard to come up with a test plan for this issue. But it is obviously a problem that if several columns with the same name is included the resulting rows will not be well defined when fetched as hashes. I know that there is code that crashes when the subscriptionhistory entry is missing. This patch do not fix all problems, however. The real problem is that the database schema is flawed. The history table should, if designed according to normal database principles, contain one entry per historic number. But it seem to be designed to always contain exactly one entry that that enumerates the historic numbers in one attribute. However, deletes in the biblio table cascades to the subscriptionhistory table, so the subscriptionhistory entry can be missing. Note that the biblionumber in the history entry may be different from the biblionumber in the subscription.