From c7493439c7fce4cfbba68b4e0b57c0fa47952433 Mon Sep 17 00:00:00 2001 From: Jonathan Druart Date: Thu, 25 Aug 2016 10:01:59 +0100 Subject: [PATCH] Bug 10455: Remove biblioitems.marc Any discussions about biblioitems.marc bring to the same conclusion: This field is useless and should be removed. We are storing MARC data into 2 different fields, that does not make sense. Test plan: Add / update / export / import /delete records should work as before Signed-off-by: Mason James Signed-off-by: Nick Clemens Signed-off-by: Kyle M Hall --- C4/Biblio.pm | 10 +++++----- C4/Items.pm | 4 ++-- C4/Overdues.pm | 3 +-- 3 files changed, 8 insertions(+), 9 deletions(-) diff --git a/C4/Biblio.pm b/C4/Biblio.pm index f846e7d6ad..97631d1886 100644 --- a/C4/Biblio.pm +++ b/C4/Biblio.pm @@ -159,7 +159,7 @@ Biblio.pm contains functions for managing storage and editing of bibliographic d =item 2. as raw MARC in the Zebra index and storage engine -=item 3. as raw MARC the biblioitems.marc and biblioitems.marcxml +=item 3. as MARC XML in biblioitems.marcxml =back @@ -183,7 +183,7 @@ Because of this design choice, the process of managing storage and editing is a =item 2. _koha_* - low-level internal functions for managing the koha tables -=item 3. Marc management function : as the MARC record is stored in biblioitems.marc(xml), some subs dedicated to it's management are in this package. They should be used only internally by Biblio.pm, the only official entry points being AddBiblio, AddItem, ModBiblio, ModItem. +=item 3. Marc management function : as the MARC record is stored in biblioitems.marcxml, some subs dedicated to it's management are in this package. They should be used only internally by Biblio.pm, the only official entry points being AddBiblio, AddItem, ModBiblio, ModItem. =item 4. Zebra functions used to update the Zebra index @@ -211,7 +211,7 @@ When dealing with items, we must : =item 2. add the itemnumber to the item MARC field -=item 3. overwrite the MARC record (with the added item) into biblioitems.marc(xml) +=item 3. overwrite the MARC record (with the added item) into biblioitems.marcxml When modifying a biblio or an item, the behaviour is quite similar. @@ -232,8 +232,8 @@ framework code. This function also accepts a third, optional argument: a hashref to additional options. The only defined option is C, which if present and mapped to a true value, causes C -to omit the call to save the MARC in C -and C This option is provided B +to omit the call to save the MARC in C +This option is provided B for the use of scripts such as C that may need to do some manipulation of the MARC record for item parsing before saving it and which cannot afford the performance hit of saving diff --git a/C4/Items.pm b/C4/Items.pm index 7c5dfe6992..858afa404c 100644 --- a/C4/Items.pm +++ b/C4/Items.pm @@ -335,8 +335,8 @@ embedded item fields. This routine is suitable for batch jobs. This API assumes that the bib record has already been saved to the C and C tables. It does -not expect that C and C -are populated, but it will do so via a call to ModBibiloMarc. +not expect that C are populated, but it +will do so via a call to ModBibiloMarc. The goal of this API is to have a similar effect to using AddBiblio and AddItems in succession, but without inefficient repeated diff --git a/C4/Overdues.pm b/C4/Overdues.pm index d0df42653d..08a222913b 100644 --- a/C4/Overdues.pm +++ b/C4/Overdues.pm @@ -160,7 +160,7 @@ Returns a count and a list of overdueitems for a given borrowernumber sub checkoverdues { my $borrowernumber = shift or return; - # don't select biblioitems.marc or biblioitems.marcxml... too slow on large systems + # don't select biblioitems.marcxml... too slow on large systems my $sth = C4::Context->dbh->prepare( "SELECT biblio.*, items.*, issues.*, biblioitems.volume, @@ -197,7 +197,6 @@ sub checkoverdues { WHERE issues.borrowernumber = ? AND issues.date_due < NOW()" ); - # FIXME: SELECT * across 4 tables? do we really need the marc AND marcxml blobs?? $sth->execute($borrowernumber); my $results = $sth->fetchall_arrayref({}); return ( scalar(@$results), $results); # returning the count and the results is silly -- 2.39.5