@@ -, +, @@ --- C4/Biblio.pm | 10 +++++----- C4/Items.pm | 4 ++-- C4/Overdues.pm | 3 +-- 3 files changed, 8 insertions(+), 9 deletions(-) --- a/C4/Biblio.pm +++ a/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 --- a/C4/Items.pm +++ a/C4/Items.pm @@ -327,8 +327,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 --- a/C4/Overdues.pm +++ a/C4/Overdues.pm @@ -159,7 +159,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, @@ -196,7 +196,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 --