- Koha-devel - lists.koha-community.org

MySQL - case insensitive
by Tomas Cohen Arazi 22 Feb '13

22 Feb '13

Hi, I've been working on some patches and realised the collation we use for it in Koha is case insensitive. This might have diverse side effects. As of authorised values (which i've been dealing with) I'd like to ask if it is ok they are case insensitive. If so, we should properly document it, and when creating a new category that is named the same (case insensitive) a previously defined one, we should alert the user instead of just adding the new authorised value. Anyway, I just wanted to hear your thoughts about this prior to filling a bug on this. Regards To+

2 1

Returning all orders for a biblionumber
by Mathieu Saby 22 Feb '13

22 Feb '13

Hello For a dev I am trying to write, I need a sub returning all the orders (or ordernumbers) linked to a specific biblionumber. Do you know if there is something like that in C4? Regards, M. Saby Rennes 2 university -- Mathieu Saby Service d'Informatique Documentaire Service Commun de la Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby(a)univ-rennes2.fr

1 0

Authority Marc Structure Import/Export Function
by David Cook 22 Feb '13

22 Feb '13

Hi all: What do folks think about adding an import/export function for the authorities marc structure frameworks? Chris has already done a great RDA framework for MARC bibliographic frameworks, which you can find here for download (http://wiki.koha-community.org/wiki/MARC_frameworks) However, RDA also creates changes to the MARC authority frameworks, and currently the only way to update those is for each library to manually update their authority MARC structures. If we have an import/export function, existing libraries can export and post their MARC authority frameworks so that everyone else can import it and save themselves some time and hassle. While MARC authority frameworks might not be as variable as bibliographic frameworks, since they are "authorities", it might not hurt to have this functionality in place for future updates to the MARC or for custom localizations. Description: logo David Cook Systems Librarian Prosentient Systems P/L ABN 31 078 409 168 72/330 Wattle St, Ultimo NSW 2007 tel: 02 92120899 fax: 02 92120885 <mailto:dcook@prosentient.com.au> dcook(a)prosentient.com.au

2 1

Reminder about updatedatabase stanzas
by Jared Camins-Esakov 21 Feb '13

21 Feb '13

Good morning. Just a reminder that if you are copying an updatedatabase stanza, you *MUST* update the message that is printed for the user to reflect what your new database update does. It should include both a description and the bug number for *YOUR* bug. I have fixed this several times, but after the bug I'm looking at now, I am simply going to fail any patch that fails to update the message with something relevant. Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins(a)cpbibliography.com (web) http://www.cpbibliography.com/

3 2

Amazon Cover Images
by Sophie Meynieux 21 Feb '13

21 Feb '13

Hi, Some of our clients are using AmazonCoverImages or OPACAmazonCoverImages system preferences to display cover of items. But sometimes no cover is found although it exists in Amazon catalog. It is because images are identified by an internal number (ASIN) in Amazon whereas Koha uses ISBN. For old books, ASIN and ISBN10 are the same, but since ISBN13 exists, ASIN and ISBN do not match any more. This is explained here (I could not find the same page in english, but maybe you it could be translated) : https://partenaires.amazon.fr/gp/associates/help/t23/a1 It seems that Amazon provides some services to find ASIN from any ISBN but it's not clear for me how to use it. Has anyone already try them ? Sophie -- Responsable support BibLibre + 33 (0)4 91 81 35 08 http://www.biblibre.com

17 30

Some database indexes are missing
by Fridolyn SOMERS 21 Feb '13

21 Feb '13

Hie, I've just created Bug 9681 to propose to add some indexes in database. Those indexes are very important to speed up SQL queries, sometimes 100x faster. I think it can help form some queries in code but mainly for statistical reports. Feel free to discuss. Best regards, -- Fridolyn SOMERS Biblibre - Pôle Support fridolyn.somers(a)biblibre.com <mailto:fridolyn.somers@biblibre.com>

1 0

Re: [Koha-devel] Koha-devel Digest, Vol 87, Issue 23
by Sandeep Bhavsar 20 Feb '13

20 Feb '13

Thanks fridolyn somers On Wed, Feb 20, 2013 at 4:30 PM, < koha-devel-request(a)lists.koha-community.org> wrote: > Send Koha-devel mailing list submissions to > koha-devel(a)lists.koha-community.org > > To subscribe or unsubscribe via the World Wide Web, visit > > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > or, via email, send a message with subject or body 'help' to > koha-devel-request(a)lists.koha-community.org > > You can reach the person managing the list at > koha-devel-owner(a)lists.koha-community.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Koha-devel digest..." > > > Today's Topics: > > 1. Re: git repository (Fridolyn SOMERS) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 19 Feb 2013 14:23:54 +0100 > From: Fridolyn SOMERS <fridolyn.somers(a)biblibre.com> > To: koha-devel(a)lists.koha-community.org > Subject: Re: [Koha-devel] git repository > Message-ID: <51237CEA.30807(a)biblibre.com> > Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" > > Hie, > > to upgrade a git repo created with "git clone": > - git remote update > - git rebase origin/master > If you want stable version, use "origin/3.10.x". > > Le 04/02/2013 06:55, SANDEEP BHAVSAR a ?crit : > > Respected All > > > > I am new to git, Kindly guide me which command shall I give now for > > upgrading my koha version. > > > > -------------------------------- > > > > You asked me to pull without telling me which branch you > > want to merge with, and 'branch.koha.merge' in > > your configuration file does not tell me either. Please > > specify which branch you want to merge on the command line and > > try again (e.g. 'git pull <repository> <refspec>'). > > See git-pull(1) for details. > > > > If you often merge with the same branch, you may want to > > configure the following variables in your configuration > > file: > > > > branch.koha.remote = <nickname> > > branch.koha.merge = <remote-ref> > > remote.<nickname>.url = <url> > > remote.<nickname>.fetch = <refspec> > > > > See git-config(1) for details. > > > -------------------------------------------------------------------------------------- > > > > -- > Fridolyn SOMERS > Biblibre - P?le Support > fridolyn.somers(a)biblibre.com <mailto:fridolyn.somers@biblibre.com> >

1 0

git repository
by SANDEEP BHAVSAR 19 Feb '13

19 Feb '13

Respected All I am new to git, Kindly guide me which command shall I give now for upgrading my koha version. -------------------------------- You asked me to pull without telling me which branch you want to merge with, and 'branch.koha.merge' in your configuration file does not tell me either. Please specify which branch you want to merge on the command line and try again (e.g. 'git pull <repository> <refspec>'). See git-pull(1) for details. If you often merge with the same branch, you may want to configure the following variables in your configuration file: branch.koha.remote = <nickname> branch.koha.merge = <remote-ref> remote.<nickname>.url = <url> remote.<nickname>.fetch = <refspec> See git-config(1) for details. -------------------------------------------------------------------------------------- -- Thanks and Regards Sandeep Bhavsar Librarian Dr.V.N.Bedekar Institute of Management Studies Thane(W) 400601 MUMBAI. INDIA @@@@@@@@@@@@@@@@@@@@@@@@@@ email : sandeep.bhavsar(a)gmail.com Mob : 9987049099 elibrary :http://www.vpmthane.org/im/elib/main.htm @@@@@@@@@@@@@@@@@@@@@@@@@@

2 1

Re: [Koha-devel] Bug 3069
by Archives and Collections Society 18 Feb '13

18 Feb '13

At 08:01 AM 2/18/2013 +0000, Marcel de Rooy wrote: >You could use the cron job cleanup_database.. for that purpose. Many thanks for the suggestion -- a script that was "unknown to me" until today. I like the idea of adding dates into the logic, and the fact that import_records cascades to import_biblios (and import_items and import_record_matches.) I'll try it on the sandbox later today or tomorrow. Best regards -- Paul >-----Oorspronkelijk bericht----- >Van: koha-devel-bounces(a)lists.koha-community.org >[mailto:koha-devel-bounces@lists.koha-community.org] Namens Paul >Verzonden: zaterdag 16 februari 2013 23:51 >Aan: Koha Devel >Onderwerp: [Koha-devel] Bug 3069 > >This bug refers to the Z39.50 "reservoir" which cannot be [easily] emptied. >A quick look in MySQL shows that we have: >mysql> SELECT COUNT(*) FROM import_records; >+----------+ >| COUNT(*) | >+----------+ >| 148357 | >+----------+ >1 row in set (0.01 sec) > >and the exact same in import_biblios (none in either import_items or >import_record_matches) -- this relates to 29,410 valid biblios in our >catalogue. > >mysql> SHOW TABLE STATUS LIKE 'import_records'; tells me that this table >has a Data_length of 1040508672 or just over 1 Gbyte. > >Is there a downside to deleting this data? [TRUNCATE TABLE import_records; >same for import_biblios] *Limited* testing in my sandbox has shown no >downside or side effects. > >The upside is a measurable improvement in the search time from >koha-admin/cgi-bin/koha/cataloguing/addbooks.pl, and speed/size >improvements for backups. > >My cataloguers tell me that they never use the "reservoir" as it only >corresponds to historical data from previous multi-Z39.50 server searches >from which they already selected the "best fit" and thought that they had >discarded the rest. As an aside, I'd be curious to know how other libraries >use this data. > >Thanks and best regards, >Paul > >_______________________________________________ >Koha-devel mailing list >Koha-devel(a)lists.koha-community.org >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >website : http://www.koha-community.org/ >git : http://git.koha-community.org/ >bugs : http://bugs.koha-community.org/

1 0

Bug 3069
by Paul 18 Feb '13

18 Feb '13

This bug refers to the Z39.50 "reservoir" which cannot be [easily] emptied. A quick look in MySQL shows that we have: mysql> SELECT COUNT(*) FROM import_records; +----------+ | COUNT(*) | +----------+ | 148357 | +----------+ 1 row in set (0.01 sec) and the exact same in import_biblios (none in either import_items or import_record_matches) -- this relates to 29,410 valid biblios in our catalogue. mysql> SHOW TABLE STATUS LIKE 'import_records'; tells me that this table has a Data_length of 1040508672 or just over 1 Gbyte. Is there a downside to deleting this data? [TRUNCATE TABLE import_records; same for import_biblios] *Limited* testing in my sandbox has shown no downside or side effects. The upside is a measurable improvement in the search time from koha-admin/cgi-bin/koha/cataloguing/addbooks.pl, and speed/size improvements for backups. My cataloguers tell me that they never use the "reservoir" as it only corresponds to historical data from previous multi-Z39.50 server searches from which they already selected the "best fit" and thought that they had discarded the rest. As an aside, I'd be curious to know how other libraries use this data. Thanks and best regards, Paul

2 1