Bug 9121 - C4::Serial SQL possible collision on subscription.subscriptionid and subscriptionhistory.subscriptionid
Summary: C4::Serial SQL possible collision on subscription.subscriptionid and subscrip...
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Serials (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low minor (vote)
Assignee: Bugs List
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-11-20 21:51 UTC by Chris Hall
Modified: 2023-01-08 01:55 UTC (History)
2 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Hall 2012-11-20 21:51:05 UTC
In C4::serials a few queries use queries of the form
SELECT subscription.*, subscriptionhistory.*
FROM subscription
LEFT JOIN subscriptionhisotry USING(subscriptionid)

If there are is a subscription without a matching subscriptionhistory then this join results in
subscription.subscriptionid | subscriptionhistory.subscriptionid
----------------------------------------------------------------
1234                        |  NULL

Once this is fetched and squashed in to a hashref (for example, via fetchall_arrayref) this will be
{ subscriptionid => undef }

This implicitly requires that every subscription has a matching subscriptionhistory.

If we change the subscriptionhistory.* to select only the parts we need then we can avoid this issue.

For SearchSubscription (which is only used by serials/serials-search.pl) none of the columns from subscriptionhistory appear to be used.

We could also add a 'subscription.subscriptionid' to the end of the select, but this seems less clean.
Comment 1 Katrin Fischer 2023-01-08 01:55:45 UTC
When looking at the table structure for subscriptions for a migration I realized that you always need to set all the tables in order to have a working and adjustable subscription: subscription, subsriptionhistory and also a first serial - I wonder if this wouldn't be more of a data issue?