From z.tajoli at cineca.it Mon Sep 1 10:21:28 2014 From: z.tajoli at cineca.it (Zeno Tajoli) Date: Mon, 01 Sep 2014 10:21:28 +0200 Subject: [Koha-devel] Testing UTF-8 (bug 11944) Message-ID: <54042C88.5060508@cineca.it> Hi to all, Paola Rossi and I we have finished to test bug 11944 using Biblibre git branch (http://git.biblibre.com/biblibre/kohac/commits/ft/bug_11944) I will be part of IRC dev meeting of today to speak about it. Bye Zeno Tajoli -- Dr. Zeno Tajoli Soluzioni per la Ricerca Istituzionale - Automazione Biblioteche z.tajoli at cineca.it fax +39 02 2135520 CINECA - Sede operativa di Segrate From jonathan.druart at biblibre.com Mon Sep 1 10:32:15 2014 From: jonathan.druart at biblibre.com (Jonathan Druart) Date: Mon, 1 Sep 2014 10:32:15 +0200 Subject: [Koha-devel] Testing UTF-8 (bug 11944) In-Reply-To: <54042C88.5060508@cineca.it> References: <54042C88.5060508@cineca.it> Message-ID: Thanks to both of you for testing! The development IRC meeting is tomorrow : http://wiki.koha-community.org/wiki/Development_IRC_meeting,_2_September_2014 Cheers, Jonathan 2014-09-01 10:21 GMT+02:00 Zeno Tajoli : > Hi to all, > > Paola Rossi and I we have finished to test bug 11944 using Biblibre git > branch (http://git.biblibre.com/biblibre/kohac/commits/ft/bug_11944) > > I will be part of IRC dev meeting of today to speak about it. > > Bye > Zeno Tajoli > > > -- > Dr. Zeno Tajoli > Soluzioni per la Ricerca Istituzionale - Automazione Biblioteche > z.tajoli at cineca.it > fax +39 02 2135520 > CINECA - Sede operativa di Segrate > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ From mathsabypro at gmail.com Mon Sep 1 23:52:49 2014 From: mathsabypro at gmail.com (Mathieu Saby) Date: Mon, 01 Sep 2014 23:52:49 +0200 Subject: [Koha-devel] Bugs related to Zebra indexing for Unimarc In-Reply-To: <53FC918E.60806@gmail.com> References: <53FC408C.9030101@gmail.com> <53FC519A.5030906@cineca.it> <53FC65FA.8030000@gmail.com> <53FC8EFF.2040605@cineca.it> <53FC918E.60806@gmail.com> Message-ID: <5404EAB1.2080402@gmail.com> Hello I wrote a patch for managing "groups of subfields" and indexing them as a whole in a phrase index : Bug 9352 (the 3rd patch). Mathieu Le 26/08/2014 15:54, Mathieu Saby a ?crit : > > Le 26/08/2014 15:43, Zeno Tajoli a ?crit : >> Hi all >> Il 26/08/2014 12:48, Mathieu Saby ha scritto: >>>> As first step for au:phr we need: >>>> >>>> >>> xmlns="http://www.koha-community.org/schemas/index-defs" tag="700" >>>> subfields="abdg"> >>>> ... >>>> >>>> >>>> a different entry from the entry of au:word that is: >>>> >>> xmlns="http://www.koha-community.org/schemas/index-defs" tag="700" >>>> subfields="bdg"> >>>> ... >>>> >>>> >>> >>> Why not "abdg" for the second entry? >> >> >> I fact my only idea is that there is an error at line 317 of your path. >> The line is: >> > xmlns="http://www.koha-community.org/schemas/index-defs" tag="700" >> subfields="bdg"> >> >> but for phrase it needs to be so: >> > xmlns="http://www.koha-community.org/schemas/index-defs" tag="700" >> subfields="abdg"> >> >> Why for phrases and not for word ? >> Because there is the line 309 in the patch (304 in master): >> > xmlns="http://www.koha-community.org/schemas/index-defs" tag="700" >> subfields="a"> >> >> So the word's indexes for 700$a are OK, but not phrase. > > > OK, in fact my patch was just trying to preserve the indexing of $a > (only) in "author:sort" index > Currently it does: > index 700$a in auhor:w, author:p, author:s > and > index 700$bdg in author:w, author:p > > I could do > index 700$a in author:s > and > index 700$abdg in author:w, author:p > > But don't know if it is best ;-) > > Mathieu > >> >>> Are we allowed to use new elements or attributes in *-koha-*.xml >>> files ? >> I think yes, namespace declaration is present only to be complian >> with xml tools, but it is not really present. >> >>> There is a namespace defined in the file : >>> xmlns:kohaidx="http://www.koha-community.org/schemas/index-defs". But I >>> cannot find the definitions either on koha-community.org, or elsewhere. >>> Do you know if it is avaiable somewhere? >> No, I think that >> kohaidx="http://www.koha-community.org/schemas/index-defs" >> and >> xmlns="http://www.koha-community.org/schemas/index-defs" >> are here only for the sake of xsltproc. >> >> Bye >> Zeno Tajoli >> >> > -- Mathieu Saby ?l?ve conservateur d'?tat - DCB 23 ENSSIB From z.tajoli at cineca.it Wed Sep 3 15:31:18 2014 From: z.tajoli at cineca.it (Zeno Tajoli) Date: Wed, 03 Sep 2014 15:31:18 +0200 Subject: [Koha-devel] New package for koha (master version) Message-ID: <54071826.3060703@cineca.it> Hi to all, I have installed koha on a Linux debian wheezy amd64. I installed packages with koha-common, I find those new packages: Test::MockObject [not mandatory, new] DBIx::Class::Schema::Loader [mandatory, too old version, at least version 0.07039]. To install Test::MockObject it is enough the package libtest-mockobject-perl for wheezy. To install DBIx::Class::Schema::Loader the package libdbix-class-schema-loader-perl of wheezy it is not enough (the version is 0.07025). In debian jessie the version is ok (0.07041), I don't know if it is a good policy to insert it in Koha repo. Bye Zeno Tajoli -- Dr. Zeno Tajoli Soluzioni per la Ricerca Istituzionale - Automazione Biblioteche z.tajoli at cineca.it fax +39 02 2135520 CINECA - Sede operativa di Segrate From tomascohen at gmail.com Wed Sep 3 15:41:00 2014 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Wed, 3 Sep 2014 10:41:00 -0300 Subject: [Koha-devel] New package for koha (master version) In-Reply-To: <54071826.3060703@cineca.it> References: <54071826.3060703@cineca.it> Message-ID: Good question Zeno. I'd say that DBIx::Class::Schema::Loader is only needed for developing. On Wed, Sep 3, 2014 at 10:31 AM, Zeno Tajoli wrote: > Hi to all, > > I have installed koha on a Linux debian wheezy amd64. > I installed packages with koha-common, I find those new packages: > > Test::MockObject [not mandatory, new] > DBIx::Class::Schema::Loader [mandatory, too old version, at least version > 0.07039]. > > To install Test::MockObject it is enough the package > libtest-mockobject-perl for wheezy. > > To install DBIx::Class::Schema::Loader the package > libdbix-class-schema-loader-perl of wheezy it is not enough (the version > is 0.07025). > > In debian jessie the version is ok (0.07041), I don't know if it is a good > policy to insert it in Koha repo. > > Bye > Zeno Tajoli > > -- > Dr. Zeno Tajoli > Soluzioni per la Ricerca Istituzionale - Automazione Biblioteche > z.tajoli at cineca.it > fax +39 02 2135520 > CINECA - Sede operativa di Segrate > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -- Tom?s Cohen Arazi Prosecretar?a de Inform?tica Universidad Nacional de C?rdoba ? +54 351 5353750 ext 13168 GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From fridolin.somers at biblibre.com Wed Sep 3 17:53:38 2014 From: fridolin.somers at biblibre.com (Fridolin SOMERS) Date: Wed, 03 Sep 2014 17:53:38 +0200 Subject: [Koha-devel] Koha 3.14.10 released Message-ID: <54073982.9020002@biblibre.com> The Koha community is proud to announce the release of 3.14.10. This is a maintenance release and contains some enhancements and several bugfixes. As always you can download the release from http://download.koha-community.org. Have a look at release post : http://koha-community.org/koha-3-14-10-released "Get the pie while it's hot" Regards, -- Fridolin SOMERS Biblibre - P?les support et syst?me fridolin.somers at biblibre.com From kohanews at gmail.com Wed Sep 3 23:14:52 2014 From: kohanews at gmail.com (Koha News) Date: Wed, 03 Sep 2014 14:14:52 -0700 Subject: [Koha-devel] Koha Community Newsletter: August 2014 Message-ID: <540784CC.8010306@gmail.com> Fellow Koha users: The Koha Community Newsletter for August 2014 is here: http://koha-community.org/koha-community-newsletter-august-2014/ Many thanks to all the folks who submitted articles and news to this month's newsletter. Please feel free to email us with any corrections or suggestions. Thanks! Chad Roseburg Joanne Dillon Editors, Koha Community Newsletter From robin at catalyst.net.nz Thu Sep 4 05:33:32 2014 From: robin at catalyst.net.nz (Robin Sheat) Date: Thu, 04 Sep 2014 15:33:32 +1200 Subject: [Koha-devel] Koha 3.14.10 released In-Reply-To: <54073982.9020002@biblibre.com> References: <54073982.9020002@biblibre.com> Message-ID: <1409801612.19603.13.camel@zarathud.wgtn.cat-it.co.nz> Fridolin SOMERS schreef op wo 03-09-2014 om 17:53 [+0200]: > The Koha community is proud to announce the release of 3.14.10. Beware that this includes Bug 8044 (Localization for Perl scripts and modules), and as such requires a new dependency. This means that any upgrades are going to be more problematic than they should be. So, for the packages at least, this will require a dist-upgrade to pull in the new dependencies. -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part URL: From ecarrazana at uci.cu Thu Sep 4 14:26:17 2014 From: ecarrazana at uci.cu (Edisnel Carrazana Castro) Date: Thu, 4 Sep 2014 08:26:17 -0400 (CDT) Subject: [Koha-devel] problem with the title field in MARC 21 In-Reply-To: References: Message-ID: <1231525909.1661915.1409833577049.JavaMail.zimbra@uci.cu> Greetings to all. I have problems with the length of the title field (245-a) in MARC 21. When a very long title is entered, the application does not save the record in the database. I am using koha 3.0.6. Any help would come fine, thanks Concurso "Mi selfie por los 5". Detalles en http://justiciaparaloscinco.wordpress.com From oleonard at myacpl.org Thu Sep 4 14:48:13 2014 From: oleonard at myacpl.org (Owen Leonard) Date: Thu, 4 Sep 2014 08:48:13 -0400 Subject: [Koha-devel] problem with the title field in MARC 21 In-Reply-To: <1231525909.1661915.1409833577049.JavaMail.zimbra@uci.cu> References: <1231525909.1661915.1409833577049.JavaMail.zimbra@uci.cu> Message-ID: > When a very long title is entered, the application does not save the > record in the database. How long is "very long?" > I am using koha 3.0.6. 3.0.6 is very old. It is highly recommended that you upgrade. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From indradg at gmail.com Mon Sep 8 06:59:38 2014 From: indradg at gmail.com (Indranil Das Gupta) Date: Mon, 8 Sep 2014 04:59:38 +0000 Subject: [Koha-devel] What purpose do the 003 and 005 tageditor popup anchors serve? Message-ID: Hi, I noticed that 003 and 005 tageditors do not actually have a popup to back them up. That unlike LDR (000), 007, 008 the tags 003 and 005 do not call any window.open function and their respective Clictag_ functions are blank. what is the purpose for having these tageditor links around for these two? curious to know :) -- Indranil Das Gupta Phone : +91-98300-20971 Blog : http://indradg.randomink.org/blog IRC : indradg on irc://irc.freenode.net Twitter : indradg -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=- Please exchange editable Office documents only in ODF Format. No other format is acceptable. Support Open Standards. For a free editor supporting ODF, please visit LibreOffice - http://www.documentfoundation.org From arosello at uci.cu Mon Sep 8 16:21:35 2014 From: arosello at uci.cu (Adnier =?utf-8?Q?Rosell=C3=B3?= Carrazana) Date: Mon, 8 Sep 2014 10:21:35 -0400 (CDT) Subject: [Koha-devel] problem to perform a simple query In-Reply-To: <1492682814.22738501.1410186061548.JavaMail.zimbra@uci.cu> Message-ID: <90370813.22738617.1410186095479.JavaMail.zimbra@uci.cu> hi all, I need to know if the search system koha have any character limitation to perform a simple query (without using zebra), I'm doing a search where the record title has 180 characters and the system does not respond so the browser (firefox) closes the connection, thanks for everything, I hope there is some solution, Greetings Concurso "Mi selfie por los 5". Detalles en http://justiciaparaloscinco.wordpress.com From gmc at esilibrary.com Mon Sep 8 17:58:47 2014 From: gmc at esilibrary.com (Galen Charlton) Date: Mon, 8 Sep 2014 08:58:47 -0700 Subject: [Koha-devel] What purpose do the 003 and 005 tageditor popup anchors serve? In-Reply-To: References: Message-ID: Hi, On Sun, Sep 7, 2014 at 9:59 PM, Indranil Das Gupta wrote: > I noticed that 003 and 005 tageditors do not actually have a popup to > back them up. That unlike LDR (000), 007, 008 the tags 003 and 005 do > not call any window.open function and their respective > Clictag_ functions are blank. > > what is the purpose for having these tageditor links around for these two? > > curious to know :) There's no particular reason for these to have tageditor links - as you surmise, the only action of the plugins is to populate (empty) 003 and 005 fields with default values. Consequently, the links could be removed, as they do nothing -- although if we do that, perhaps there should be some alternative visual indication that something special happens if one clicks in those fields. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc at esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org From indradg at gmail.com Mon Sep 8 18:28:38 2014 From: indradg at gmail.com (Indranil Das Gupta) Date: Mon, 8 Sep 2014 16:28:38 +0000 Subject: [Koha-devel] What purpose do the 003 and 005 tageditor popup anchors serve? In-Reply-To: References: Message-ID: Hi, On Mon, Sep 8, 2014 at 3:58 PM, Galen Charlton wrote: > > On Sun, Sep 7, 2014 at 9:59 PM, Indranil Das Gupta wrote: > There's no particular reason for these to have tageditor links - as > you surmise, the only action of the plugins is to populate (empty) 003 > and 005 fields with default values. The max role I can see for 003 tageditor link is to provide a link to set MarcOrgCode syspref but then that is handled elsewhere. Perhaps a z39.50 server list alike link to this page - http://www.loc.gov/marc/authority/ecadorg.html and its provider links? For example, http://www.loc.gov/marc/organizations/org-search.php?org_keyword=L2C2+Technologies&submit=Search pulls up my data in the LOC Org code db. It could be wrapped into an impromptu API (as long as LOC does not change *their* db lookup process) Does something like that even make any sense? I'm just thinking aloud here (so I might be talking utter BS :P) cheers, -indra -- Indranil Das Gupta Phone : +91-98300-20971 Blog : http://indradg.randomink.org/blog IRC : indradg on irc://irc.freenode.net Twitter : indradg -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=- Please exchange editable Office documents only in ODF Format. No other format is acceptable. Support Open Standards. For a free editor supporting ODF, please visit LibreOffice - http://www.documentfoundation.org From gmc at esilibrary.com Mon Sep 8 18:57:15 2014 From: gmc at esilibrary.com (Galen Charlton) Date: Mon, 8 Sep 2014 09:57:15 -0700 Subject: [Koha-devel] What purpose do the 003 and 005 tageditor popup anchors serve? In-Reply-To: References: Message-ID: Hi, On Mon, Sep 8, 2014 at 9:28 AM, Indranil Das Gupta wrote: > The max role I can see for 003 tageditor link is to provide a link to > set MarcOrgCode syspref but then that is handled elsewhere. Perhaps a > z39.50 server list alike link to this page - > http://www.loc.gov/marc/authority/ecadorg.html and its provider links? > > For example, http://www.loc.gov/marc/organizations/org-search.php?org_keyword=L2C2+Technologies&submit=Search > pulls up my data in the LOC Org code db. It could be wrapped into an > impromptu API (as long as LOC does not change *their* db lookup > process) > > Does something like that even make any sense? I'm just thinking aloud > here (so I might be talking utter BS :P) I think providing access to the whole LC organization code list would be overkill unless you're using a Koha database as part of your workflow to do contract cataloging for a bunch of libraries. What might be useful for a consortium would be allowing more than one value for MarcOrgCode. In fact, that's already the topic of bug 10132 (MarcOrgCode would be useful on branch level). [1] [1] http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10132 Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc at esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org From indradg at gmail.com Mon Sep 8 19:24:15 2014 From: indradg at gmail.com (Indranil Das Gupta) Date: Mon, 8 Sep 2014 17:24:15 +0000 Subject: [Koha-devel] What purpose do the 003 and 005 tageditor popup anchors serve? In-Reply-To: References: Message-ID: Hi, On Mon, Sep 8, 2014 at 4:57 PM, Galen Charlton wrote: > On Mon, Sep 8, 2014 at 9:28 AM, Indranil Das Gupta wrote: > What might be useful for a consortium would be allowing more than one > value for MarcOrgCode. In fact, that's already the topic of bug 10132 > (MarcOrgCode would be useful on branch level). Point taken. Will be trying my hand with that one. Should not be too tough. cheers -indra -- Indranil Das Gupta Phone : +91-98300-20971 Blog : http://indradg.randomink.org/blog IRC : indradg on irc://irc.freenode.net Twitter : indradg -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=- Please exchange editable Office documents only in ODF Format. No other format is acceptable. Support Open Standards. For a free editor supporting ODF, please visit LibreOffice - http://www.documentfoundation.org From kyle.m.hall at gmail.com Tue Sep 9 19:21:36 2014 From: kyle.m.hall at gmail.com (Kyle Hall) Date: Tue, 9 Sep 2014 13:21:36 -0400 Subject: [Koha-devel] Koha and DBIC Message-ID: As discussed in #koha, I think we are not using DBIC as well as we could. Right now we are only using it to replace hand written SQL queries. I would propose the following: 1) Allow find and simple searches in pl. 2) If a search is used more than once, it should be a ResultSet method 3) If a subroutine operates on a single table row, it should be a Result method 4) If a subroutine operates on a single table, it should be a ResultSet method 5) Any operation that works on tables linked by key constraints should take advantage of those DBIC relationships and also In this way we can do things like: $borrower->is_debarred or $borrower->has_overdues or @borrowers = $borrower->guarantees() Any search can be a method in the ResultSet such as $borrower->issue()->overdue_issues(); or my @records_with_holds = $schema->resultset('Biblio')->with_holds() I think in the long run this will make or code far more readable, testable, and efficient. What do you think? Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Wed Sep 10 08:26:38 2014 From: dcook at prosentient.com.au (David Cook) Date: Wed, 10 Sep 2014 16:26:38 +1000 Subject: [Koha-devel] Koha and DBIC In-Reply-To: References: Message-ID: <024e01cfccc0$2d427170$87c75450$@prosentient.com.au> Hi Kyle: Could you speak more to what a ResultSet method would be? From what I?ve seen Koha::Schema::* just has Results in it. Would we need to define custom ResultSets as well to get this kind of functionality? Overall, this sounds good to me. It would be nice to put more of the ?database? code into one place, and have more of the ?logic? or processing elsewhere. Like you say, more readable, testable, efficient. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Kyle Hall Sent: Wednesday, 10 September 2014 3:22 AM To: Koha Devel Subject: [Koha-devel] Koha and DBIC As discussed in #koha, I think we are not using DBIC as well as we could. Right now we are only using it to replace hand written SQL queries. I would propose the following: 1) Allow find and simple searches in pl. 2) If a search is used more than once, it should be a ResultSet method 3) If a subroutine operates on a single table row, it should be a Result method 4) If a subroutine operates on a single table, it should be a ResultSet method 5) Any operation that works on tables linked by key constraints should take advantage of those DBIC relationships and also In this way we can do things like: $borrower->is_debarred or $borrower->has_overdues or @borrowers = $borrower->guarantees() Any search can be a method in the ResultSet such as $borrower->issue()->overdue_issues(); or my @records_with_holds = $schema->resultset('Biblio')->with_holds() I think in the long run this will make or code far more readable, testable, and efficient. What do you think? Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.de.Rooy at rijksmuseum.nl Wed Sep 10 08:39:19 2014 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Wed, 10 Sep 2014 06:39:19 +0000 Subject: [Koha-devel] Koha and DBIC In-Reply-To: <024e01cfccc0$2d427170$87c75450$@prosentient.com.au> References: , <024e01cfccc0$2d427170$87c75450$@prosentient.com.au> Message-ID: <809BE39CD64BFD4EB9036172EBCCFA31423BB34B@S-MAIL-1B.rijksmuseum.intra> And what about deploying instead of kohastructure.sql ? Same for DBIx statements in updatedatabase.. The current process was meant to be temporary (adding SQL in kohastructure and updatedatabase and having the RM update the DBIx scheme). ________________________________ Van: koha-devel-bounces at lists.koha-community.org [koha-devel-bounces at lists.koha-community.org] namens David Cook [dcook at prosentient.com.au] Verzonden: woensdag 10 september 2014 8:26 Aan: 'Kyle Hall'; 'Koha Devel' Onderwerp: Re: [Koha-devel] Koha and DBIC Hi Kyle: Could you speak more to what a ResultSet method would be? From what I?ve seen Koha::Schema::* just has Results in it. Would we need to define custom ResultSets as well to get this kind of functionality? Overall, this sounds good to me. It would be nice to put more of the ?database? code into one place, and have more of the ?logic? or processing elsewhere. Like you say, more readable, testable, efficient. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Kyle Hall Sent: Wednesday, 10 September 2014 3:22 AM To: Koha Devel Subject: [Koha-devel] Koha and DBIC As discussed in #koha, I think we are not using DBIC as well as we could. Right now we are only using it to replace hand written SQL queries. I would propose the following: 1) Allow find and simple searches in pl. 2) If a search is used more than once, it should be a ResultSet method 3) If a subroutine operates on a single table row, it should be a Result method 4) If a subroutine operates on a single table, it should be a ResultSet method 5) Any operation that works on tables linked by key constraints should take advantage of those DBIC relationships and also In this way we can do things like: $borrower->is_debarred or $borrower->has_overdues or @borrowers = $borrower->guarantees() Any search can be a method in the ResultSet such as $borrower->issue()->overdue_issues(); or my @records_with_holds = $schema->resultset('Biblio')->with_holds() I think in the long run this will make or code far more readable, testable, and efficient. What do you think? Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.druart at biblibre.com Wed Sep 10 11:00:45 2014 From: jonathan.druart at biblibre.com (Jonathan Druart) Date: Wed, 10 Sep 2014 11:00:45 +0200 Subject: [Koha-devel] Koha and DBIC In-Reply-To: References: Message-ID: Hi all, IMO a ResultSet should not be instantiate in a pl script for some reasons (I already listed yesterday, nothing new :)) - should be unit tested - easier to maintain - easier to reuse But I don't think it's a big deal. I think someone (don't remember who) explained it is not a good idea to add too much changes to the ResultSet class. I tend to agree. In your example: $borrower->is_debarred Where do you instantiate $borrower? And where is defined is_debarred? I would write something like I have written for Koha::Acquisition::Order (bug 12830) package Koha::Borrower; use Koha::Schema; use base qw( Class::Accessor ); sub fetch { my ( $class, $borrowernumber ) = @_; my $borrower = Koha::Database->new->schema->resultset('Borrower')->find($borrowernumber, {result_class => 'DBIx::Class::ResultClass::HashRefInflator' } ); return $class->new( $borrower ); } sub is_debarred { my ( $self ) = @_; my $debarred_date = $self->{debarred}; return $debarred_date > $today; } in the pl file: my $borrower = Koha::Borrower->fetch( $borrowernumber ); The limitation in this implementation is that $borrower is not a DBIC object and we would like to get rid of HashRefInflator. Please comment this part of code and share yours! Cheers, Jonathan 2014-09-09 19:21 GMT+02:00 Kyle Hall : > As discussed in #koha, I think we are not using DBIC as well as we could. > Right now we are only using it to replace hand written SQL queries. I would > propose the following: > > 1) Allow find and simple searches in pl. > 2) If a search is used more than once, it should be a ResultSet method > 3) If a subroutine operates on a single table row, it should be a Result > method > 4) If a subroutine operates on a single table, it should be a ResultSet > method > 5) Any operation that works on tables linked by key constraints should take > advantage of those DBIC relationships and also > > In this way we can do things like: > $borrower->is_debarred > or > $borrower->has_overdues > or > @borrowers = $borrower->guarantees() > > Any search can be a method in the ResultSet such as > $borrower->issue()->overdue_issues(); > or > my @records_with_holds = $schema->resultset('Biblio')->with_holds() > > I think in the long run this will make or code far more readable, testable, > and efficient. > > What do you think? > > Kyle > > http://www.kylehall.info > ByWater Solutions ( http://bywatersolutions.com ) > Meadville Public Library ( http://www.meadvillelibrary.org ) > Crawford County Federated Library System ( http://www.ccfls.org ) > Mill Run Technology Solutions ( http://millruntech.com ) > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ From z.tajoli at cineca.it Wed Sep 10 11:07:02 2014 From: z.tajoli at cineca.it (Zeno Tajoli) Date: Wed, 10 Sep 2014 11:07:02 +0200 Subject: [Koha-devel] Koha and DBIC In-Reply-To: References: Message-ID: <541014B6.1020102@cineca.it> Hi Kyle, Il 09/09/2014 19:21, Kyle Hall ha scritto: > 1) Allow find and simple searches in pl. > 2) If a search is used more than once, it should be a ResultSet method > 3) If a subroutine operates on a single table row, it should be a Result > method > 4) If a subroutine operates on a single table, it should be a ResultSet > method > 5) Any operation that works on tables linked by key constraints should > take advantage of those DBIC relationships and also to undestand the proposal is better to have a complete script with this points. Do you have written a patch on bug in this way ? Bye Zeno Tajoli -- Dr. Zeno Tajoli Soluzioni per la Ricerca Istituzionale - Automazione Biblioteche z.tajoli at cineca.it fax +39 02 2135520 CINECA - Sede operativa di Segrate From jonathan.druart at biblibre.com Wed Sep 10 15:35:57 2014 From: jonathan.druart at biblibre.com (Jonathan Druart) Date: Wed, 10 Sep 2014 15:35:57 +0200 Subject: [Koha-devel] TestBuilder - Pros & Cons Message-ID: Hello developers, Yesterday the TestBuilder case has been discussed during the meeting [1] I will try to list the pros and cons points as objectively as I can: Pros: - the module meets a need: simplify the writing of tests Cons: - it's another tool to learn - it should be covered by unit tests - it should be maintain - it hides the way how it works under the hood - it is not hard to create required rows in dependent tables That was the objective part. Now, since I would like to see TestBuilder [2] integrated into master, I will try to provide arguments. The need is to simplify the writing of tests, especially for the acquisition module. An easy goal could be to be data agnostic, random data could be generated as the beginning of all test files. So yes, it is another tool to learn, but the way we are writing tests for now is not elegant and maintain them will be a pain. The tool has been provided (by Yohann) with its own unit tests, no need to write them (hopefully!). The api is quite easy to learn (only 2 public methods: build and clear). I don't think this module will hide "how it works under the hood", the guys who will use them are going to add/write/rewrite a new routine and already know the DB structure. I would like to add that I don't think this module should be mandatory. A developer should be free not to use to it. Some examples have already been provided, which will help developers who want to use it. I would add that it is not "hard" to manually generate dependencies, just a waste of time. And it adds useless complexity in the tests files. When you have to create a library, a bookseller, a basket and a biblio to create an order, sometime for 1 test, it does not encourage developers to write tests. I think the best example is bug 12604 [3]. It is the same if you want to issue an item to a patron, you will have to create a library, a patron category, a patron, a biblio and the item. Developers are lazy, they just want to tell "give me a patron and an item!". I am sure this is certainly not the best implementation. It has been done by an intern in 2 weeks. He didn't know perl or Koha 1 month before. Yohann provided a very good work. Moreover he based his work on a python library doing the same thing (I don't remember the name :-/) Note that some other modules already exist [4], but they won't work out of the box like TestBuilder. Maybe for our next intern :) Cheers, Jonathan Ps: to keep in mind whose this module will be useful, you can run the following command: python gitinspector.py ~/src --since=2013-01-01 --file-types=t It will generate statistics for test files by author since 2013 (for busy guys, you can see the result here: http://paste.koha-community.org/199) [1] http://wiki.koha-community.org/wiki/Development_IRC_meeting,_9_September_2014 [2] Bug 12603 - TestBuilder - Module to simplify the writing of tests [3] Bug 12604: refactoring close_reopen_basket.t with TestBuilder [4] http://search.cpan.org/dist/DBIx-Class-Fixtures/lib/DBIx/Class/Fixtures.pm or Test::DBIx::Class:Factory From jonathan.druart at biblibre.com Wed Sep 10 17:42:57 2014 From: jonathan.druart at biblibre.com (Jonathan Druart) Date: Wed, 10 Sep 2014 17:42:57 +0200 Subject: [Koha-devel] TestBuilder - Pros & Cons In-Reply-To: References: Message-ID: I asked Yohann and he answered me: He based his module on a module of the Django framework: Model Mommy: https://pypi.python.org/pypi/model_mommy. 2014-09-10 15:35 GMT+02:00 Jonathan Druart : > Hello developers, > > Yesterday the TestBuilder case has been discussed during the meeting [1] > > I will try to list the pros and cons points as objectively as I can: > Pros: > - the module meets a need: simplify the writing of tests > > Cons: > - it's another tool to learn > - it should be covered by unit tests > - it should be maintain > - it hides the way how it works under the hood > - it is not hard to create required rows in dependent tables > > That was the objective part. > Now, since I would like to see TestBuilder [2] integrated into master, > I will try to provide arguments. > > The need is to simplify the writing of tests, especially for the > acquisition module. > An easy goal could be to be data agnostic, random data could be > generated as the beginning of all test files. > So yes, it is another tool to learn, but the way we are writing tests > for now is not elegant and maintain them will be a pain. > The tool has been provided (by Yohann) with its own unit tests, no > need to write them (hopefully!). The api is quite easy to learn (only > 2 public methods: build and clear). > I don't think this module will hide "how it works under the hood", the > guys who will use them are going to add/write/rewrite a new routine > and already know the DB structure. > I would like to add that I don't think this module should be > mandatory. A developer should be free not to use to it. > > Some examples have already been provided, which will help developers > who want to use it. > I would add that it is not "hard" to manually generate dependencies, > just a waste of time. And it adds useless complexity in the tests > files. > When you have to create a library, a bookseller, a basket and a biblio > to create an order, sometime for 1 test, it does not encourage > developers to write tests. I think the best example is bug 12604 [3]. > It is the same if you want to issue an item to a patron, you will have > to create a library, a patron category, a patron, a biblio and the > item. Developers are lazy, they just want to tell "give me a patron > and an item!". > > I am sure this is certainly not the best implementation. It has been > done by an intern in 2 weeks. He didn't know perl or Koha 1 month > before. Yohann provided a very good work. > Moreover he based his work on a python library doing the same thing (I > don't remember the name :-/) > Note that some other modules already exist [4], but they won't work > out of the box like TestBuilder. Maybe for our next intern :) > > Cheers, > Jonathan > > Ps: to keep in mind whose this module will be useful, you can run the > following command: > python gitinspector.py ~/src --since=2013-01-01 --file-types=t > It will generate statistics for test files by author since 2013 (for > busy guys, you can see the result here: > http://paste.koha-community.org/199) > > [1] http://wiki.koha-community.org/wiki/Development_IRC_meeting,_9_September_2014 > [2] Bug 12603 - TestBuilder - Module to simplify the writing of tests > [3] Bug 12604: refactoring close_reopen_basket.t with TestBuilder > [4] http://search.cpan.org/dist/DBIx-Class-Fixtures/lib/DBIx/Class/Fixtures.pm > or Test::DBIx::Class:Factory From tomascohen at gmail.com Wed Sep 10 19:28:53 2014 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Wed, 10 Sep 2014 14:28:53 -0300 Subject: [Koha-devel] KohaCon14 Message-ID: Hi, if you're coming to KohaCon14 please don't forget to fill your data here http://wiki.koha-community.org/wiki/Who_is_arriving_when at least the arrival time so we know you're arriving, safe adn happy in Cordoba. Regards To+ -- Tom?s Cohen Arazi Prosecretar?a de Inform?tica Universidad Nacional de C?rdoba ? +54 351 5353750 ext 13168 GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From robin at catalyst.net.nz Thu Sep 11 00:41:41 2014 From: robin at catalyst.net.nz (Robin Sheat) Date: Thu, 11 Sep 2014 10:41:41 +1200 Subject: [Koha-devel] Koha and DBIC In-Reply-To: References: Message-ID: <1410388901.20051.7.camel@zarathud.wgtn.cat-it.co.nz> Kyle Hall schreef op di 09-09-2014 om 13:21 [-0400]: > 1) Allow find and simple searches in pl. IMO, this is not a good idea. You're coupling database schema with code that's closer to display. All access should be via an API into the C4:: or Koha:: namespace, and the modules there are the only ones that know/care how the database is actually laid out. This means that if we want to change how things are stored[0], only one module needs to know about the change, and it can still present the same interface to code. The moment that you have more than one place talking to a fairly low-level system like the database, you are going to have problems (e.g. the issues in the current system where so many modules touch the account code that refactoring it is a huge nightmare.) [0] from fixing badly named columns/tables, to adding caching, to refactoring the schema to make it more efficient, to not using the database at all for some reason. -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part URL: From kyle.m.hall at gmail.com Thu Sep 11 02:05:36 2014 From: kyle.m.hall at gmail.com (Kyle Hall) Date: Wed, 10 Sep 2014 20:05:36 -0400 Subject: [Koha-devel] Koha and DBIC In-Reply-To: <024e01cfccc0$2d427170$87c75450$@prosentient.com.au> References: <024e01cfccc0$2d427170$87c75450$@prosentient.com.au> Message-ID: We need to create the ResultSets ourselves. We should just be able to dump them in Koha/Schema/ResultSet. I'll work on a proof of concept. Here is an example: http://blogs.perl.org/users/ovid/2014/04/custom-dbixclass-resultsets.html I agree. Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) On Wed, Sep 10, 2014 at 2:26 AM, David Cook wrote: > Hi Kyle: > > > > Could you speak more to what a ResultSet method would be? From what I?ve > seen Koha::Schema::* just has Results in it. Would we need to define custom > ResultSets as well to get this kind of functionality? > > > > Overall, this sounds good to me. It would be nice to put more of the > ?database? code into one place, and have more of the ?logic? or processing > elsewhere. Like you say, more readable, testable, efficient. > > > > > > David Cook > > Systems Librarian > > Prosentient Systems > > 72/330 Wattle St, Ultimo, NSW 2007 > > > > *From:* koha-devel-bounces at lists.koha-community.org [mailto: > koha-devel-bounces at lists.koha-community.org] *On Behalf Of *Kyle Hall > *Sent:* Wednesday, 10 September 2014 3:22 AM > *To:* Koha Devel > *Subject:* [Koha-devel] Koha and DBIC > > > > As discussed in #koha, I think we are not using DBIC as well as we could. > Right now we are only using it to replace hand written SQL queries. I would > propose the following: > > > > 1) Allow find and simple searches in pl. > > 2) If a search is used more than once, it should be a ResultSet method > > 3) If a subroutine operates on a single table row, it should be a Result > method > > 4) If a subroutine operates on a single table, it should be a ResultSet > method > > 5) Any operation that works on tables linked by key constraints should > take advantage of those DBIC relationships and also > > > > In this way we can do things like: > > $borrower->is_debarred > > or > > $borrower->has_overdues > > or > > @borrowers = $borrower->guarantees() > > > > Any search can be a method in the ResultSet such as > > $borrower->issue()->overdue_issues(); > > or > > my @records_with_holds = $schema->resultset('Biblio')->with_holds() > > > > I think in the long run this will make or code far more readable, > testable, and efficient. > > > > What do you think? > > > > Kyle > > > > http://www.kylehall.info > > ByWater Solutions ( http://bywatersolutions.com ) > Meadville Public Library ( http://www.meadvillelibrary.org ) > Crawford County Federated Library System ( http://www.ccfls.org ) > Mill Run Technology Solutions ( http://millruntech.com ) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.m.hall at gmail.com Thu Sep 11 02:07:03 2014 From: kyle.m.hall at gmail.com (Kyle Hall) Date: Wed, 10 Sep 2014 20:07:03 -0400 Subject: [Koha-devel] Koha and DBIC In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA31423BB34B@S-MAIL-1B.rijksmuseum.intra> References: <024e01cfccc0$2d427170$87c75450$@prosentient.com.au> <809BE39CD64BFD4EB9036172EBCCFA31423BB34B@S-MAIL-1B.rijksmuseum.intra> Message-ID: That is certainly a possibility. There are a few options with DBIC. However, I ended up abandoning all of them for something custom with Libki. We may have better results collectively than I did alone. Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) On Wed, Sep 10, 2014 at 2:39 AM, Marcel de Rooy wrote: > And what about deploying instead of kohastructure.sql ? > Same for DBIx statements in updatedatabase.. > The current process was meant to be temporary (adding SQL in kohastructure > and updatedatabase and having the RM update the DBIx scheme). > > ------------------------------ > *Van:* koha-devel-bounces at lists.koha-community.org [ > koha-devel-bounces at lists.koha-community.org] namens David Cook [ > dcook at prosentient.com.au] > *Verzonden:* woensdag 10 september 2014 8:26 > *Aan:* 'Kyle Hall'; 'Koha Devel' > *Onderwerp:* Re: [Koha-devel] Koha and DBIC > > Hi Kyle: > > > > Could you speak more to what a ResultSet method would be? From what I?ve > seen Koha::Schema::* just has Results in it. Would we need to define custom > ResultSets as well to get this kind of functionality? > > > > Overall, this sounds good to me. It would be nice to put more of the > ?database? code into one place, and have more of the ?logic? or processing > elsewhere. Like you say, more readable, testable, efficient. > > > > > > David Cook > > Systems Librarian > > Prosentient Systems > > 72/330 Wattle St, Ultimo, NSW 2007 > > > > *From:* koha-devel-bounces at lists.koha-community.org [mailto: > koha-devel-bounces at lists.koha-community.org] *On Behalf Of *Kyle Hall > *Sent:* Wednesday, 10 September 2014 3:22 AM > *To:* Koha Devel > *Subject:* [Koha-devel] Koha and DBIC > > > > As discussed in #koha, I think we are not using DBIC as well as we could. > Right now we are only using it to replace hand written SQL queries. I would > propose the following: > > > > 1) Allow find and simple searches in pl. > > 2) If a search is used more than once, it should be a ResultSet method > > 3) If a subroutine operates on a single table row, it should be a Result > method > > 4) If a subroutine operates on a single table, it should be a ResultSet > method > > 5) Any operation that works on tables linked by key constraints should > take advantage of those DBIC relationships and also > > > > In this way we can do things like: > > $borrower->is_debarred > > or > > $borrower->has_overdues > > or > > @borrowers = $borrower->guarantees() > > > > Any search can be a method in the ResultSet such as > > $borrower->issue()->overdue_issues(); > > or > > my @records_with_holds = $schema->resultset('Biblio')->with_holds() > > > > I think in the long run this will make or code far more readable, > testable, and efficient. > > > > What do you think? > > > > Kyle > > > > http://www.kylehall.info > > ByWater Solutions ( http://bywatersolutions.com ) > Meadville Public Library ( http://www.meadvillelibrary.org ) > Crawford County Federated Library System ( http://www.ccfls.org ) > Mill Run Technology Solutions ( http://millruntech.com ) > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.m.hall at gmail.com Thu Sep 11 02:39:10 2014 From: kyle.m.hall at gmail.com (Kyle Hall) Date: Wed, 10 Sep 2014 20:39:10 -0400 Subject: [Koha-devel] Koha and DBIC In-Reply-To: References: Message-ID: On Wed, Sep 10, 2014 at 5:00 AM, Jonathan Druart < jonathan.druart at biblibre.com> wrote: > Hi all, > > IMO a ResultSet should not be instantiate in a pl script for some > reasons (I already listed yesterday, nothing new :)) > - should be unit tested > - easier to maintain > - easier to reuse > > But I don't think it's a big deal. > I agree with all these principles, and none of them conflict with what I am proposing. Result and ResultSet methods are no different than C4/Koha methods and subroutines. > > I think someone (don't remember who) explained it is not a good idea > to add too much changes to the ResultSet class. I tend to agree. > > In your example: > $borrower->is_debarred > Where do you instantiate $borrower? And where is defined is_debarred? > Most likely you would use find(), single() or search(). In this example we could easily swith from Koha::Borrower::Debarments::IsDebarred to Koha::Schema::ResultSet::Borrower::is_debarred. There is no functional difference, and it makes more sense in the long run. I agree that any search that is even mildly complex and used in multiple places should live in the ResultSet. I'm not saying we should use search() everyone where in pl files, I'm just against a hard and fast rule forbidding it which will cause developers to jump through hoops that don't need to exist. > > I would write something like I have written for > Koha::Acquisition::Order (bug 12830) > > package Koha::Borrower; > use Koha::Schema; > use base qw( Class::Accessor ); > > sub fetch { > my ( $class, $borrowernumber ) = @_; > my $borrower = > Koha::Database->new->schema->resultset('Borrower')->find($borrowernumber, > {result_class => 'DBIx::Class::ResultClass::HashRefInflator' } ); > return $class->new( $borrower ); > } > > sub is_debarred { > my ( $self ) = @_; > my $debarred_date = $self->{debarred}; > return $debarred_date > $today; > } > > in the pl file: > my $borrower = Koha::Borrower->fetch( $borrowernumber ); > > The limitation in this implementation is that $borrower is not a DBIC > object and we would like to get rid of HashRefInflator. > > Please comment this part of code and share yours! > Can you see how this gives no advantage, but simply wraps the useful code in another layer of abstraction? There simply is no advantage to doing this. In the long run this type of thinking will make things more complicated and more error prone than they need to be. Instead of all this code we simply need to add one method to Result::Borrower. Here is the gist of it: sub is_debarred { my ( $self ) = @_; return $self->debarred_date() > dt_from_string(); } Think about all the overhead and complexity that is removed by this variation. Kyle -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.m.hall at gmail.com Thu Sep 11 02:41:32 2014 From: kyle.m.hall at gmail.com (Kyle Hall) Date: Wed, 10 Sep 2014 20:41:32 -0400 Subject: [Koha-devel] Koha and DBIC In-Reply-To: <541014B6.1020102@cineca.it> References: <541014B6.1020102@cineca.it> Message-ID: I'll work on a proof of concept. In the mean time here are a couple examples from another project I work on: http://sourceforge.net/p/bizwerks/bizwerks/ci/master/tree/lib/BizWerks/Schema/ResultSet/Department.pm http://sourceforge.net/p/bizwerks/bizwerks/ci/master/tree/lib/BizWerks/Schema/ResultSet/Field.pm http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) On Wed, Sep 10, 2014 at 5:07 AM, Zeno Tajoli wrote: > Hi Kyle, > > Il 09/09/2014 19:21, Kyle Hall ha scritto: > >> 1) Allow find and simple searches in pl. >> 2) If a search is used more than once, it should be a ResultSet method >> 3) If a subroutine operates on a single table row, it should be a Result >> method >> 4) If a subroutine operates on a single table, it should be a ResultSet >> method >> 5) Any operation that works on tables linked by key constraints should >> take advantage of those DBIC relationships and also >> > > to undestand the proposal is better to have a complete script with this > points. Do you have written a patch on bug in this way ? > > Bye > Zeno Tajoli > -- > Dr. Zeno Tajoli > Soluzioni per la Ricerca Istituzionale - Automazione Biblioteche > z.tajoli at cineca.it > fax +39 02 2135520 > CINECA - Sede operativa di Segrate > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.m.hall at gmail.com Thu Sep 11 02:51:38 2014 From: kyle.m.hall at gmail.com (Kyle Hall) Date: Wed, 10 Sep 2014 20:51:38 -0400 Subject: [Koha-devel] Koha and DBIC In-Reply-To: <1410388901.20051.7.camel@zarathud.wgtn.cat-it.co.nz> References: <1410388901.20051.7.camel@zarathud.wgtn.cat-it.co.nz> Message-ID: > > > 1) Allow find and simple searches in pl. > > IMO, this is not a good idea. You're coupling database schema with code > that's closer to display. > It's funny, I've been trying to think of an example search to justify this and I can't really think of one where we can't use existing Result relationships to get our data. Maybe find() and single() are really all we need from pl files, but I don't think a hard and fast rule against search() is a good idea. > > All access should be via an API into the C4:: or Koha:: namespace, and > the modules there are the only ones that know/care how the database is > actually laid out. This means that if we want to change how things are > stored[0], only one module needs to know about the change, and it can > still present the same interface to code. > Result and ResultSet are part of the Koha namespace. I also feel that you aren't quite correct about how one modules need to know the change a present the same interface. I can't count the number of times I've added a new parameter to an existing subroutine and had to update every function call in many perl files. Now that hashref's are more common, it's become less of a problem but it's still a problem that exists. I just don't think this is a entirely valid point. Remember, Result and ResultSet methods are no different than methods anywhere else in Koha and C4. > > The moment that you have more than one place talking to a fairly > low-level system like the database, you are going to have problems (e.g. > the issues in the current system where so many modules touch the account > code that refactoring it is a huge nightmare.) > Exactly. If you look at my accounts rewrite you'll see I didn't try to shoehorn everything into Result and ResultSet. I used a Koha module that uses Results and ResultSets in a sane fashion. Kyle > > -- > Robin Sheat > Catalyst IT Ltd. > ? +64 4 803 2204 > GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robin at catalyst.net.nz Thu Sep 11 03:19:49 2014 From: robin at catalyst.net.nz (Robin Sheat) Date: Thu, 11 Sep 2014 13:19:49 +1200 Subject: [Koha-devel] Koha and DBIC In-Reply-To: References: <1410388901.20051.7.camel@zarathud.wgtn.cat-it.co.nz> Message-ID: <1410398389.20051.24.camel@zarathud.wgtn.cat-it.co.nz> Kyle Hall schreef op wo 10-09-2014 om 20:51 [-0400]: > It's funny, I've been trying to think of an example search to justify > this and I can't really think of one where we can't use existing > Result relationships to get our data. Maybe find() and single() are > really all we need from pl files, but I don't think a hard and fast > rule against search() is a good idea. We'd still be coupling to the data storage schema, which is bad. It's exactly the same logic that says not to have SQL in the .pl files. > Result and ResultSet are part of the Koha namespace. I also feel that Only in the sense that they have Koha:: in the name. They are an API to the database, and are generated directly from the database schema. They are not an API that is designed to provide logical access to whatever it is. > you aren't quite correct about how one modules need to know the > change a present the same interface. I can't count the number of times > I've added a new parameter to an existing subroutine and had to update > every function call in many perl files. Now that hashref's are more > common, it's become less of a problem but it's still a problem that > exists. "It's been broken in the past" isn't a justification for "so we should keep it broken." As we go to a more OO and thought out method of writing things (again, especially with the Koha:: stuff), we are moving away from "here's a hashref with the fields from the biblio table" to "here's an object that represents a biblio, with accessors and modifiers." We want more of this, and less things going and talking to the database themselves. > I just don't think this is a entirely valid point. Remember, Result > and ResultSet methods are no different than methods anywhere else in > Koha and C4. They are totally different. They are much closer to an abstraction of the database, compared to an abstraction of whatever it is the data is representing. And the code at the .pl level should be working with abstractions of data, e.g. "a reserve", or "a biblio with attached items", not "a set of hashrefs containing a biblio, a biblioitem, and the associated item records." This latter is what Result/ResultSet represent. In the ES code, I've been keeping this in mind. For example, I can go (from memory): my $it = Koha::Biblio->get_iterator; while (my $bib = $it->next) { add_to_index($bib); } which means I don't have to care how they're stored. It also meant that it took very little work to refactor it to handle authorities, as everything had the same style of API. ResultSet stuff happened in the modules, but none of it was exposed to the script that was using those modules. > Exactly. If you look at my accounts rewrite you'll see I didn't try to > shoehorn everything into Result and ResultSet. I used a Koha module > that uses Results and ResultSets in a sane fashion. And that's fine. Just not at the .pl level. The job of modules is to put a sensible abstraction between the storage layer and the user interface layer. As soon as UI related code can touch the storage layer, you're violating that principle and causing maintenance headaches for the next person who comes along. > -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part URL: From kyle.m.hall at gmail.com Thu Sep 11 04:06:09 2014 From: kyle.m.hall at gmail.com (Kyle Hall) Date: Wed, 10 Sep 2014 22:06:09 -0400 Subject: [Koha-devel] Koha and DBIC In-Reply-To: <1410398389.20051.24.camel@zarathud.wgtn.cat-it.co.nz> References: <1410388901.20051.7.camel@zarathud.wgtn.cat-it.co.nz> <1410398389.20051.24.camel@zarathud.wgtn.cat-it.co.nz> Message-ID: On Wed, Sep 10, 2014 at 9:19 PM, Robin Sheat wrote: > Kyle Hall schreef op wo 10-09-2014 om 20:51 [-0400]: > > > > It's funny, I've been trying to think of an example search to justify > > this and I can't really think of one where we can't use existing > > Result relationships to get our data. Maybe find() and single() are > > really all we need from pl files, but I don't think a hard and fast > > rule against search() is a good idea. > > We'd still be coupling to the data storage schema, which is bad. It's > exactly the same logic that says not to have SQL in the .pl files. > > I'm simply saying it doesn't seem that something like search( borrowernumber => $borrowernumber ) should be abstracted away. > > > Result and ResultSet are part of the Koha namespace. I also feel that > > Only in the sense that they have Koha:: in the name. They are an API to > the database, and are generated directly from the database schema. They > are not an API that is designed to provide logical access to whatever it > is. > > We can always re-engineer our Result and ResultSet's to use any theoretical future construct. We needn't use another layer of API's. > > you aren't quite correct about how one modules need to know the > > change a present the same interface. I can't count the number of times > > I've added a new parameter to an existing subroutine and had to update > > every function call in many perl files. Now that hashref's are more > > common, it's become less of a problem but it's still a problem that > > exists. > > "It's been broken in the past" isn't a justification for "so we should > keep it broken." As we go to a more OO and thought out method of writing > things (again, especially with the Koha:: stuff), we are moving away > from "here's a hashref with the fields from the biblio table" to "here's > an object that represents a biblio, with accessors and modifiers." We > want more of this, and less things going and talking to the database > themselves. > I agree. DBIC *provides* objects that represent a biblio with accessors and modifiers. > > > I just don't think this is a entirely valid point. Remember, Result > > and ResultSet methods are no different than methods anywhere else in > > Koha and C4. > > They are totally different. They are much closer to an abstraction of > the database, compared to an abstraction of whatever it is the data is > representing. And the code at the .pl level should be working with > abstractions of data, e.g. "a reserve", or "a biblio with attached > items", not "a set of hashrefs containing a biblio, a biblioitem, and > the associated item records." This latter is what Result/ResultSet > represent. > Only if we don't take advantage of what DBIC is capable of. I agree, in the way we are using it now you are correct. That's why I've proposed what I have. > > In the ES code, I've been keeping this in mind. For example, I can go > (from memory): > > my $it = Koha::Biblio->get_iterator; > while (my $bib = $it->next) { > add_to_index($bib); > } > > which means I don't have to care how they're stored. It also meant that > it took very little work to refactor it to handle authorities, as > everything had the same style of API. ResultSet stuff happened in the > modules, but none of it was exposed to the script that was using those > modules. > > I don't see how this couldn't have been accomplished just as easily with DBIC. Biblios and authorities would also share the same DBIC methods. > > > Exactly. If you look at my accounts rewrite you'll see I didn't try to > > shoehorn everything into Result and ResultSet. I used a Koha module > > that uses Results and ResultSets in a sane fashion. > > And that's fine. Just not at the .pl level. The job of modules is to put > a sensible abstraction between the storage layer and the user interface > layer. As soon as UI related code can touch the storage layer, you're > violating that principle and causing maintenance headaches for the next > person who comes along. > > > The UI isn't touching the storage layer, its touching an abstraction layer. I'm just not for the idea of abstracting our abstraction layer. I think we are in general agreement. I just disagree about hard and fast rules that could limit the real potential we have with DBIC. Kyle -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.druart at biblibre.com Thu Sep 11 09:31:42 2014 From: jonathan.druart at biblibre.com (Jonathan Druart) Date: Thu, 11 Sep 2014 09:31:42 +0200 Subject: [Koha-devel] Koha and DBIC In-Reply-To: References: Message-ID: 2014-09-11 2:39 GMT+02:00 Kyle Hall : > On Wed, Sep 10, 2014 at 5:00 AM, Jonathan Druart > wrote: >> >> Hi all, >> >> IMO a ResultSet should not be instantiate in a pl script for some >> reasons (I already listed yesterday, nothing new :)) >> - should be unit tested >> - easier to maintain >> - easier to reuse >> >> But I don't think it's a big deal. > > > I agree with all these principles, and none of them conflict with what I am > proposing. Result and ResultSet methods are no different than C4/Koha > methods and subroutines. Yes they are, as Robin said, It is an API for the DB, not for the functional job. >> Please comment this part of code and share yours! > > Can you see how this gives no advantage, but simply wraps the useful code in > another layer of abstraction? There simply is no advantage to doing this. In > the long run this type of thinking will make things more complicated and > more error prone than they need to be. The advantage is to share responsabilities, which is already a lot. > Instead of all this code we simply need to add one method to > Result::Borrower. Here is the gist of it: > > sub is_debarred { > my ( $self ) = @_; > return $self->debarred_date() > dt_from_string(); > } > > Think about all the overhead and complexity that is removed by this > variation. I don't understand where is the complexity. We need Koha::Module packages. We cannot put all our code into Koha::Schema::Result::Module. Why everyone is afraid of abstraction layers? From colin.campbell at ptfs-europe.com Thu Sep 11 10:15:17 2014 From: colin.campbell at ptfs-europe.com (Colin Campbell) Date: Thu, 11 Sep 2014 09:15:17 +0100 Subject: [Koha-devel] Koha and DBIC In-Reply-To: <1410398389.20051.24.camel@zarathud.wgtn.cat-it.co.nz> References: <1410388901.20051.7.camel@zarathud.wgtn.cat-it.co.nz> <1410398389.20051.24.camel@zarathud.wgtn.cat-it.co.nz> Message-ID: <20140911081517.GA3065@zazou.cscnet.co.uk> Its worth keeping in mind that DBIC is an Object Relational mapper and that as such returns objects which are often better abstrations than those currently embodied in Koha's module approach which tend to fiddle with the representation of the entity not always very consistently. In a multitude of cases a ResultSet of x objects and their inherent getters and setters is all we need to construct the operations we need. In such cases wrapping the layer in another one for purely formal reasons contributes little except for more space to harbour bugs. DBIC allows you to add extra methods to these objects and I'm sure in time we'll identify plenty of these but we should be very thorough in reviewing whether we need them, how we've implemented them and whether the need is merely pointing up a shortcoming in the schema. Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 800 756 6803 (phone) +44 (0) 7759 633626 (mobile) colin.campbell at ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com From kyle.m.hall at gmail.com Thu Sep 11 13:29:57 2014 From: kyle.m.hall at gmail.com (Kyle Hall) Date: Thu, 11 Sep 2014 07:29:57 -0400 Subject: [Koha-devel] Koha and DBIC In-Reply-To: References: Message-ID: On Thu, Sep 11, 2014 at 3:31 AM, Jonathan Druart < jonathan.druart at biblibre.com> wrote: > 2014-09-11 2:39 GMT+02:00 Kyle Hall : > > On Wed, Sep 10, 2014 at 5:00 AM, Jonathan Druart > > wrote: > >> > >> Hi all, > >> > >> IMO a ResultSet should not be instantiate in a pl script for some > >> reasons (I already listed yesterday, nothing new :)) > >> - should be unit tested > >> - easier to maintain > >> - easier to reuse > >> > >> But I don't think it's a big deal. > > > > > > I agree with all these principles, and none of them conflict with what I > am > > proposing. Result and ResultSet methods are no different than C4/Koha > > methods and subroutines. > > Yes they are, as Robin said, It is an API for the DB, not for the > functional job. > Again, only if we treat it that way. We can leverage DBIC to add formality and commonality to our OO code where it's always been bespoke implementations previously. > > >> Please comment this part of code and share yours! > > > > Can you see how this gives no advantage, but simply wraps the useful > code in > > another layer of abstraction? There simply is no advantage to doing > this. In > > the long run this type of thinking will make things more complicated and > > more error prone than they need to be. > > The advantage is to share responsabilities, which is already a lot. > I don't understand your comment. > > > Instead of all this code we simply need to add one method to > > Result::Borrower. Here is the gist of it: > > > > sub is_debarred { > > my ( $self ) = @_; > > return $self->debarred_date() > dt_from_string(); > > } > > > > Think about all the overhead and complexity that is removed by this > > variation. > > I don't understand where is the complexity. We need Koha::Module > packages. We cannot put all our code into > Koha::Schema::Result::Module. > Why everyone is afraid of abstraction layers? > We *don't* need Koha::Module packages for everything! My point is that DBIC provides us with an abstraction layer already! Wrapping a DBIC class in another class provides no advantage and just obfuscates our code, increases hardware requirements, and leaves more room to introduce bugs. If we are just going to use DBIC to avoid writing direct sql queries, we should be using something like Fey instead. We are a collective of developers with many different styles and opinions. We often have very different approaches to how we implement new features. If we go down this path of wrapping DBIC in another abstraction layer, we simply continue down this patch of having many different bespoke implementations. If we use dbic as our abstraction layer, we remove much of that issue. Kyle -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.m.hall at gmail.com Thu Sep 11 13:32:03 2014 From: kyle.m.hall at gmail.com (Kyle Hall) Date: Thu, 11 Sep 2014 07:32:03 -0400 Subject: [Koha-devel] Koha and DBIC In-Reply-To: <20140911081517.GA3065@zazou.cscnet.co.uk> References: <1410388901.20051.7.camel@zarathud.wgtn.cat-it.co.nz> <1410398389.20051.24.camel@zarathud.wgtn.cat-it.co.nz> <20140911081517.GA3065@zazou.cscnet.co.uk> Message-ID: I completely agree. You've described the issue more succinctly and eloquently than I have by far. Kyle On Thu, Sep 11, 2014 at 4:15 AM, Colin Campbell < colin.campbell at ptfs-europe.com> wrote: > Its worth keeping in mind that DBIC is an Object Relational mapper and > that as such returns objects which are often better abstrations than > those currently embodied in Koha's module approach which tend to fiddle > with the representation of the entity not always very consistently. In a > multitude of cases a ResultSet of x objects and their inherent getters > and setters is all we need to construct the operations we need. In such > cases wrapping the layer in another one for purely formal reasons > contributes little except for more space to harbour bugs. > DBIC allows you to add extra methods to these objects and I'm sure in > time we'll identify plenty of these but we should be very thorough in > reviewing whether we need them, how we've implemented them and whether > the need is merely pointing up a shortcoming in the schema. > > Colin > > -- > Colin Campbell > Chief Software Engineer, > PTFS Europe Limited > Content Management and Library Solutions > +44 (0) 800 756 6803 (phone) > +44 (0) 7759 633626 (mobile) > colin.campbell at ptfs-europe.com > skype: colin_campbell2 > > http://www.ptfs-europe.com > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.druart at biblibre.com Thu Sep 11 14:09:33 2014 From: jonathan.druart at biblibre.com (Jonathan Druart) Date: Thu, 11 Sep 2014 14:09:33 +0200 Subject: [Koha-devel] Koha and DBIC In-Reply-To: References: Message-ID: 2014-09-11 13:29 GMT+02:00 Kyle Hall : >> > Can you see how this gives no advantage, but simply wraps the useful >> > code in >> > another layer of abstraction? There simply is no advantage to doing >> > this. In >> > the long run this type of thinking will make things more complicated and >> > more error prone than they need to be. >> >> The advantage is to share responsabilities, which is already a lot. > > > I don't understand your comment. Not important, I just repeated myself: the functional job should not be done under the Koha::Schema::Result. It should only contain DB relationships without any intelligence on what happen above. >> > Instead of all this code we simply need to add one method to >> > Result::Borrower. Here is the gist of it: >> > >> > sub is_debarred { >> > my ( $self ) = @_; >> > return $self->debarred_date() > dt_from_string(); >> > } >> > >> > Think about all the overhead and complexity that is removed by this >> > variation. >> >> I don't understand where is the complexity. We need Koha::Module >> packages. We cannot put all our code into >> Koha::Schema::Result::Module. >> Why everyone is afraid of abstraction layers? > > > We *don't* need Koha::Module packages for everything! My point is that DBIC > provides us with an abstraction layer already! Wrapping a DBIC class in > another class provides no advantage and just obfuscates our code, increases > hardware requirements, and leaves more room to introduce bugs. If we are > just going to use DBIC to avoid writing direct sql queries, we should be > using something like Fey instead. Give me examples please: Which "modules" don't need specific packages? IMO, these ones should have their own modules: Order, Supplier, Biblio, Item, Issue, Authorised value, Suggestion, Library, Budget, Fund, Patron. > We are a collective of developers with many different styles and opinions. I completely agree with that :) That fact is that DBIC has been pushed into Koha 1 year ago and we don't have any plan. I tried several times and my patches have just been rejected. We never had this discussion (I mean a real/constructive discussion), nobody gives examples. I really would like someone shows me what he has in mind, like I did for Koha::Acquisition::[Order|Bookseller]. > We often have very different approaches to how we implement new features. If > we go down this path of wrapping DBIC in another abstraction layer, we > simply continue down this patch of having many different bespoke > implementations. If we use dbic as our abstraction layer, we remove much of > that issue. I we reach an agreement, we can do what we want. I hope some of you will be in Cordoba in 3 weeks! :) From mtompset at hotmail.com Thu Sep 11 14:13:31 2014 From: mtompset at hotmail.com (Mark Tompsett) Date: Thu, 11 Sep 2014 08:13:31 -0400 Subject: [Koha-devel] Koha and DBIC In-Reply-To: References: Message-ID: Greetings, Fey?! Please, let?s not add more technologies (Haskell that compiles to Javascript) in for geekiness sake. I have been reading this dialogue between Robin and Kyle and thinking to myself, ?Why was DBIC added in the first place? Was it not to increase portability (where is that ?it does not run on Postgresql!? person) , ?simplify? (at the cost of another learning curve) data access, and provide a cleaner abstraction for data access?? So, why was it added? Was it added to be more Object Oriented (OO) so we could use it in the way that is being discussed? So, I?ll reiterate my question again, which I think will bring some clarity to the discussion, what was the point of adding DBIC? GPML, Mark Tompsett P.S. Abstractions are okay, but abstractions upon abstractions are ugly for the initial learning curve. If you want people to join the coding community, multiple levels of abstractions make it more difficult. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.m.hall at gmail.com Thu Sep 11 14:54:22 2014 From: kyle.m.hall at gmail.com (Kyle Hall) Date: Thu, 11 Sep 2014 08:54:22 -0400 Subject: [Koha-devel] Koha and DBIC In-Reply-To: References: Message-ID: > > > >> I don't understand where is the complexity. We need Koha::Module > >> packages. We cannot put all our code into > >> Koha::Schema::Result::Module. > >> Why everyone is afraid of abstraction layers? > > > > > > We *don't* need Koha::Module packages for everything! My point is that > DBIC > > provides us with an abstraction layer already! Wrapping a DBIC class in > > another class provides no advantage and just obfuscates our code, > increases > > hardware requirements, and leaves more room to introduce bugs. If we are > > just going to use DBIC to avoid writing direct sql queries, we should be > > using something like Fey instead. > > Give me examples please: Which "modules" don't need specific packages? > IMO, these ones should have their own modules: Order, Supplier, > Biblio, Item, Issue, Authorised value, Suggestion, Library, Budget, > Fund, Patron. > Why do you believe these need Koha modules? Each one of these already has an object with methods via DBIC. We can add more methods either for a given Library via Result::Branch, or for a collection of libraries via ResultSet::Branch > > We are a collective of developers with many different styles and > opinions. > > I completely agree with that :) > That fact is that DBIC has been pushed into Koha 1 year ago and we > don't have any plan. I tried several times and my patches have just > been rejected. > We never had this discussion (I mean a real/constructive discussion), > nobody gives examples. > I really would like someone shows me what he has in mind, like I did > for Koha::Acquisition::[Order|Bookseller]. > I'd really love to get a chance to write something that exemplifies this. So far the only bit has been Result::Item::effective_itemtype() > > > We often have very different approaches to how we implement new > features. If > > we go down this path of wrapping DBIC in another abstraction layer, we > > simply continue down this patch of having many different bespoke > > implementations. If we use dbic as our abstraction layer, we remove much > of > > that issue. > > I we reach an agreement, we can do what we want. > > I hope some of you will be in Cordoba in 3 weeks! :) > I wish I was going! Unfortunately, with a baby in the house I've made the decision not to attend this year. It was not an easy decision to make, and I'll miss getting to see everyone. I hope any discussions regarding these issues will continue to take place here and on #koha so I can participate! Kyle -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.m.hall at gmail.com Thu Sep 11 14:59:05 2014 From: kyle.m.hall at gmail.com (Kyle Hall) Date: Thu, 11 Sep 2014 08:59:05 -0400 Subject: [Koha-devel] Koha and DBIC In-Reply-To: References: Message-ID: On Thu, Sep 11, 2014 at 8:13 AM, Mark Tompsett wrote: > Greetings, > > Fey?! Please, let?s not add more technologies (Haskell that compiles to > Javascript) in for geekiness sake. > Heh, not Fay, Fey ; ) http://search.cpan.org/~drolsky/Fey-0.40/lib/Fey.pm > I have been reading this dialogue between Robin and Kyle and thinking to > myself, ?Why was DBIC added in the first place? Was it not to increase > portability (where is that ?it does not run on Postgresql!? person) , > ?simplify? (at the cost of another learning curve) data access, and provide > a cleaner abstraction for data access?? So, why was it added? Was it added > to be more Object Oriented (OO) so we could use it in the way that is being > discussed? So, I?ll reiterate my question again, which I think will bring > some clarity to the discussion, what was the point of adding DBIC? > I had always thought it was yes to all those. We discussed the issues in Edinburgh. That's where the idea of adding another layer of abstraction was proposed and later discarded. > P.S. Abstractions are okay, but abstractions upon abstractions are ugly > for the initial learning curve. If you want people to join the coding > community, multiple levels of abstractions make it more difficult. > Agreed. That is why I'm making these suggestions. Kyle -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.druart at biblibre.com Thu Sep 11 15:34:34 2014 From: jonathan.druart at biblibre.com (Jonathan Druart) Date: Thu, 11 Sep 2014 15:34:34 +0200 Subject: [Koha-devel] Koha and DBIC In-Reply-To: References: Message-ID: 2014-09-11 14:59 GMT+02:00 Kyle Hall : > I had always thought it was yes to all those. We discussed the issues in > Edinburgh. That's where the idea of adding another layer of abstraction was > proposed and later discarded. I was not in Edinburgh and did know stuffs have been discussed. Nothing is writing somewhere, right? So we need to write it now :) From philippe.blouin at inlibro.com Thu Sep 11 15:35:18 2014 From: philippe.blouin at inlibro.com (Philippe Blouin) Date: Thu, 11 Sep 2014 09:35:18 -0400 Subject: [Koha-devel] Koha and DBIC In-Reply-To: References: Message-ID: <5411A516.5030107@inlibro.com> +1 On 09/11/2014 08:13 AM, Mark Tompsett wrote: > Greetings, > Fey?! Please, let's not add more technologies (Haskell that compiles > to Javascript) in for geekiness sake. I have been reading this > dialogue between Robin and Kyle and thinking to myself, "Why was DBIC > added in the first place? Was it not to increase portability (where is > that 'it does not run on Postgresql!' person) , 'simplify' (at the > cost of another learning curve) data access, and provide a cleaner > abstraction for data access?" So, why was it added? Was it added to be > more Object Oriented (OO) so we could use it in the way that is being > discussed? So, I'll reiterate my question again, which I think will > bring some clarity to the discussion, what was the point of adding DBIC? > GPML, > Mark Tompsett > P.S. Abstractions are okay, but abstractions upon abstractions are > ugly for the initial learning curve. If you want people to join the > coding community, multiple levels of abstractions make it more difficult. > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ -- Philippe Blouin, Responsable du d?veloppement informatique T?l. : (888) 604-2627 philippe.blouin at inLibro.com inLibro | pour esprit libre | www.inLibro.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.m.hall at gmail.com Thu Sep 11 15:52:18 2014 From: kyle.m.hall at gmail.com (Kyle Hall) Date: Thu, 11 Sep 2014 09:52:18 -0400 Subject: [Koha-devel] Koha and DBIC In-Reply-To: References: Message-ID: There should be a page on the wiki somewhere. I recall authoring it. Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) On Thu, Sep 11, 2014 at 9:34 AM, Jonathan Druart < jonathan.druart at biblibre.com> wrote: > 2014-09-11 14:59 GMT+02:00 Kyle Hall : > > I had always thought it was yes to all those. We discussed the issues in > > Edinburgh. That's where the idea of adding another layer of abstraction > was > > proposed and later discarded. > > I was not in Edinburgh and did know stuffs have been discussed. > Nothing is writing somewhere, right? > So we need to write it now :) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.druart at biblibre.com Thu Sep 11 15:56:41 2014 From: jonathan.druart at biblibre.com (Jonathan Druart) Date: Thu, 11 Sep 2014 15:56:41 +0200 Subject: [Koha-devel] Koha and DBIC In-Reply-To: References: Message-ID: 2014-09-11 14:54 GMT+02:00 Kyle Hall : >> Give me examples please: Which "modules" don't need specific packages? >> IMO, these ones should have their own modules: Order, Supplier, >> Biblio, Item, Issue, Authorised value, Suggestion, Library, Budget, >> Fund, Patron. > > > Why do you believe these need Koha modules? Each one of these already has an > object with methods via DBIC. We can add more methods either for a given > Library via Result::Branch, or for a collection of libraries via > ResultSet::Branch Just because in my feeling, they need their own module. To share responsibilities. This abstraction is not a way to make the logic/architecture complicated, but to simplify it. I am not a fan of 2k packages lines... > I'd really love to get a chance to write something that exemplifies this. So > far the only bit has been Result::Item::effective_itemtype() Just a quick example would give me what you think. With biblio or patron, or whatever. I am waiting for examples for 1 year now. >> I we reach an agreement, we can do what we want. >> >> I hope some of you will be in Cordoba in 3 weeks! :) > > I wish I was going! Unfortunately, with a baby in the house I've made the > decision not to attend this year. It was not an easy decision to make, and > I'll miss getting to see everyone. I hope any discussions regarding these > issues will continue to take place here and on #koha so I can participate! Too bad! From colin.campbell at ptfs-europe.com Thu Sep 11 16:11:41 2014 From: colin.campbell at ptfs-europe.com (Colin Campbell) Date: Thu, 11 Sep 2014 15:11:41 +0100 Subject: [Koha-devel] Koha and DBIC In-Reply-To: References: Message-ID: <20140911141141.GA12146@zazou.cscnet.co.uk> On Thu, Sep 11, 2014 at 08:13:31AM -0400, Mark Tompsett wrote: > I?ll reiterate my question again, which I think will bring some clarity to the discussion, > what was the point of adding DBIC? > One reason implicit was so that we could benefit from the work that's gone into it rather than re-inventing bits of it with varying success as we have done repeatedly and not too consistently. C. -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 800 756 6803 (phone) +44 (0) 7759 633626 (mobile) colin.campbell at ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com From dcook at prosentient.com.au Fri Sep 12 03:31:14 2014 From: dcook at prosentient.com.au (David Cook) Date: Fri, 12 Sep 2014 11:31:14 +1000 Subject: [Koha-devel] Koha and DBIC In-Reply-To: <20140911081517.GA3065@zazou.cscnet.co.uk> References: <1410388901.20051.7.camel@zarathud.wgtn.cat-it.co.nz> <1410398389.20051.24.camel@zarathud.wgtn.cat-it.co.nz> <20140911081517.GA3065@zazou.cscnet.co.uk> Message-ID: <035501cfce29$3e013040$ba0390c0$@prosentient.com.au> Hi Colin: Well said! I think that the shortcomings in the schema are definitely part of the issue here. For instance, the "biblio" table isn't really an accurate representation of a "Biblio" object, even/especially via DBIC. That's because a proper "Biblio" object is actually an amalgam of "biblio" and "biblioitems". Likewise, a proper "Biblio" object should also be shared with "deletedbiblio" and "deletedbiblioitems". There's also "biblioimages". I think that's what Robin was referring to when he talked about the need for having Koha:: objects. As Robin was saying, DBIC is an abstraction layer for the database. It is a much more convenient way of dealing with the database, but it seems to me that it's still all about CRUD. As Jonathan was saying, the purpose of having Koha:: objects is to add logical functionality. To make it a "Koha" object. That said, I think Colin and Kyle have good points about not wanting to abstract the abstraction, as it does add overhead. DBIC can be slow. Plus, the more layers, the more possible bugs. But unless I'm missing something... DBIC can't give us a single "Biblio" object that would contain data from "biblio" and "biblioitems" or "deletedbiblio" and "deletedbiblioitems". We would need a "Koha" object. Now... that's probably because of shortcomings with the schema, like Colin mentioned. But... it seems to me that we're stuck with the schema for the moment. Maybe "Biblio" isn't a good example, as it's a difficult one. Maybe something simpler... "reserves" and "old_reserves" wouldn't work. "issues" and "old_issues" wouldn't work. Unless maybe I'm missing how you create the ResultSet classes. That could be. (The "biblio" and "biblioitems" example would still probably be a problem though?) I don't know how this DBIC idea could work in many cases. Take subscriptions. There are several tables that deal with subscriptions. Or "messages". Wouldn't we want a "Koha" class that interacts with multiple tables via DBIC? Objects are cool, because you can store data and methods in them, but it seems to me that we should be thinking about our objects as "things" rather than tables. A "Biblio" touches several tables, or could be populated by several different tables. There are 4 "oai_set*" tables but we'd only want 1 "oai_set" object. Maybe I'm thinking about this too simplistically or too abstractly, as I don't have a code example at hand. I keep going back to this "Biblio" idea though (perhaps because biblio records are so key to Koha). It would have something like "save" and "delete" methods. The save method would add/update the "biblio" and "biblioitems" tables. The delete method would delete from "biblio" and "biblioitems" and write to "deletedbiblio" and "deletedbiblio" items. Likewise, there could be "image" methods for controlling the images associated with that bib. I suppose the downside of the image methods would be... you wouldn't necessarily want to load the whole biblio object just to get to the images, but I suppose you wouldn't have to. Koha::Biblio could be really lightweight. You could just give it a biblionumber, then do all sorts of functions related to that biblionumber without loading the marcxml or the biblio/biblioitems data. I'm looking at http://sourceforge.net/p/bizwerks/bizwerks/ci/master/tree/lib/BizWerks/Schem a/ResultSet/Department.pm but I don't see how the children() method works. It would be nice to have something like that with Biblio as well, so you can get the "children items". The attached orders. The attached reservations. All which would be their own "Koha" objects. I don't quite understand how the custom ResultSet methods would work. Maybe you could have custom ResultSet methods for Biblio that would get attached orders and attached reservations which might be DBIC objects. Yet... we also have "import_items". So I'd rather have a "Koha" object for "Item". But then if we're using "Koha" objects for "Item" and "Biblio", why would we not have "Koha" objects for "Reserves" and "Orders" which are more than just data. They have logic. Can this item be placed on reserve? I think that's similar to the "apply_security_policy" example given at http://search.cpan.org/~ribasushi/DBIx-Class-0.08270/lib/DBIx/Class/ResultSe t.pm. This seems to imply an application-level object using the DBIC object. Maybe it is silly if we just build simple wrappers around simple DBIC objects, but I think a fair bit of the code in Koha is more complex than just CRUD. I'm skeptical but I'm intrigued. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 > -----Original Message----- > From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel- > bounces at lists.koha-community.org] On Behalf Of Colin Campbell > Sent: Thursday, 11 September 2014 6:15 PM > To: koha-devel at lists.koha-community.org > Subject: Re: [Koha-devel] Koha and DBIC > > Its worth keeping in mind that DBIC is an Object Relational mapper and that > as such returns objects which are often better abstrations than those > currently embodied in Koha's module approach which tend to fiddle with the > representation of the entity not always very consistently. In a multitude of > cases a ResultSet of x objects and their inherent getters and setters is all we > need to construct the operations we need. In such cases wrapping the layer > in another one for purely formal reasons contributes little except for more > space to harbour bugs. > DBIC allows you to add extra methods to these objects and I'm sure in time > we'll identify plenty of these but we should be very thorough in reviewing > whether we need them, how we've implemented them and whether the > need is merely pointing up a shortcoming in the schema. > > Colin > > -- > Colin Campbell > Chief Software Engineer, > PTFS Europe Limited > Content Management and Library Solutions > +44 (0) 800 756 6803 (phone) > +44 (0) 7759 633626 (mobile) > colin.campbell at ptfs-europe.com > skype: colin_campbell2 > > http://www.ptfs-europe.com > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ From jonathan.druart at biblibre.com Fri Sep 12 09:43:10 2014 From: jonathan.druart at biblibre.com (Jonathan Druart) Date: Fri, 12 Sep 2014 09:43:10 +0200 Subject: [Koha-devel] Koha and DBIC In-Reply-To: <035501cfce29$3e013040$ba0390c0$@prosentient.com.au> References: <1410388901.20051.7.camel@zarathud.wgtn.cat-it.co.nz> <1410398389.20051.24.camel@zarathud.wgtn.cat-it.co.nz> <20140911081517.GA3065@zazou.cscnet.co.uk> <035501cfce29$3e013040$ba0390c0$@prosentient.com.au> Message-ID: 2014-09-12 3:31 GMT+02:00 David Cook : > That said, I think Colin and Kyle have good points about not wanting to > abstract the abstraction, as it does add overhead. DBIC can be slow. Plus, > the more layers, the more possible bugs. We need to create a Koha API, a good and better API. For that the only way to do is to add Koha classes to wrap the DBIC ResultSet classes (note that we could extend it). I really don't think performance will be impacted here. The difference can be ignore. I disagree with the "more layers, more bugs" idea. An abstraction layer adds flexibility and a better overview. For instance, I think we should have a Koha::Record class. Biblio and Authority would be a Koha::Record. Do you think this new class adds more complexity? To me it adds consistence and the common code will be refactored in this class. > But unless I'm missing something... DBIC can't give us a single "Biblio" > object that would contain data from "biblio" and "biblioitems" or > "deletedbiblio" and "deletedbiblioitems". We would need a "Koha" object. > Now... that's probably because of shortcomings with the schema, like Colin > mentioned. But... it seems to me that we're stuck with the schema for the > moment. Maybe "Biblio" isn't a good example, as it's a difficult one. Maybe > something simpler... Koha has a lot of complex concepts. Because it offers a lot of modules and possibilities to the users. Koha has to work for every configuration across the world. Biblio won't be a special case. So there are not reason to cut the class in 2 groups: the simple and the complex. All lot will need their own modules, because we need to be flexible and logical. > I'm skeptical but I'm intrigued. Thanks to share your interest :) You managed to tell what I didn't. From kyle.m.hall at gmail.com Fri Sep 12 13:47:34 2014 From: kyle.m.hall at gmail.com (Kyle Hall) Date: Fri, 12 Sep 2014 07:47:34 -0400 Subject: [Koha-devel] Koha and DBIC In-Reply-To: References: <1410388901.20051.7.camel@zarathud.wgtn.cat-it.co.nz> <1410398389.20051.24.camel@zarathud.wgtn.cat-it.co.nz> <20140911081517.GA3065@zazou.cscnet.co.uk> <035501cfce29$3e013040$ba0390c0$@prosentient.com.au> Message-ID: On Fri, Sep 12, 2014 at 3:43 AM, Jonathan Druart < jonathan.druart at biblibre.com> wrote: > 2014-09-12 3:31 GMT+02:00 David Cook : > > That said, I think Colin and Kyle have good points about not wanting to > > abstract the abstraction, as it does add overhead. DBIC can be slow. > Plus, > > the more layers, the more possible bugs. > > We need to create a Koha API, a good and better API. For that the only > way to do is to add Koha classes to wrap the DBIC ResultSet classes > (note that we could extend it). > This ^. That's the solution. If we extend the resultset class then we can retain all the DBIC methods and retain the ability to leverage all the strengths of DBIC. For example, let's say we want to carp/die if a particular key isn't passed to create(), or maybe we any delete to fail if there's still a row in table X that's related to it. All we need to do is use inheritance so we can test our conditions, then call the parent's create(), or delete() or whatever method. > I really don't think performance will be impacted here. The difference > can be ignore. > I disagree with the "more layers, more bugs" idea. An abstraction > layer adds flexibility and a better overview. > For instance, I think we should have a Koha::Record class. Biblio and > Authority would be a Koha::Record. > We can use multiple inheritance or Roles ( interfaces in OO terminology ) to achieve this. That way each Biblio and Authority share a common set of methods and can be used interchangeably in certain circumstances. > Do you think this new class adds more complexity? To me it adds > consistence and the common code will be refactored in this class. > But unless I'm missing something... DBIC can't give us a single "Biblio" > > object that would contain data from "biblio" and "biblioitems" or > > "deletedbiblio" and "deletedbiblioitems". We would need a "Koha" object. > > Now... that's probably because of shortcomings with the schema, like > Colin > > mentioned. But... it seems to me that we're stuck with the schema for the > > moment. Maybe "Biblio" isn't a good example, as it's a difficult one. > Maybe > > something simpler... > DBIC can't give us a single record object technically, because of our schema ( the tables should be merged into one at this point in time ). However, we can solve this in two ways. We can either just write $biblio->biblioitem->marcxml and say it's not a big deal, or we can just add methods for each of the biblioitem methods so we can just treat them as one object: sub marcxml { my $self = (@_); return $self->biblioitem->marcxml; } We can have a method that returns a MARC::Record, or perhaps we could even have our Result::Biblio inherit from MARC::Record, and our ResultSet::Biblio inherit from MARC::Batch. Koha has a lot of complex concepts. Because it offers a lot of modules > and possibilities to the users. Koha has to work for every > configuration across the world. > Biblio won't be a special case. So there are not reason to cut the > class in 2 groups: the simple and the complex. > All lot will need their own modules, because we need to be flexible and > logical. I absolutely agree. I think at the simplest we can use our Result and ResultSet classes, at the next level we can extend our Result and ResultSet classes, and at the far end of the spectrum we have fancy classes that don't map easily to the database but use DBIC objects to get things done. > > > I'm skeptical but I'm intrigued. > > Thanks to share your interest :) > You managed to tell what I didn't. > Agreed! Kyle -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.m.hall at gmail.com Fri Sep 12 13:55:46 2014 From: kyle.m.hall at gmail.com (Kyle Hall) Date: Fri, 12 Sep 2014 07:55:46 -0400 Subject: [Koha-devel] Koha and DBIC In-Reply-To: References: <1410388901.20051.7.camel@zarathud.wgtn.cat-it.co.nz> <1410398389.20051.24.camel@zarathud.wgtn.cat-it.co.nz> <20140911081517.GA3065@zazou.cscnet.co.uk> <035501cfce29$3e013040$ba0390c0$@prosentient.com.au> Message-ID: ?This appears to be an excellent read on ways to extend and enhance Result and ResultSet: https://github.com/castaway/dbix-class-book/blob/master/chapters/06-Components-and-extending.md Kyle -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.m.hall at gmail.com Fri Sep 12 19:11:48 2014 From: kyle.m.hall at gmail.com (Kyle Hall) Date: Fri, 12 Sep 2014 13:11:48 -0400 Subject: [Koha-devel] Koha and DBIC In-Reply-To: References: <1410388901.20051.7.camel@zarathud.wgtn.cat-it.co.nz> <1410398389.20051.24.camel@zarathud.wgtn.cat-it.co.nz> <20140911081517.GA3065@zazou.cscnet.co.uk> <035501cfce29$3e013040$ba0390c0$@prosentient.com.au> Message-ID: I have written a bit of proof of concept code as an alternative implementation of http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10363 Please let me know what you think! If you compare the original proposed Koha::AuthorisedValue with my alternate implementation, I think you'll see how much less code is needed. This makes it easier to understand, lowers the barrier to entry for new developers, reduces the chance of bugs and reduces overhead. Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomascohen at gmail.com Sun Sep 14 16:19:13 2014 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Sun, 14 Sep 2014 11:19:13 -0300 Subject: [Koha-devel] Koha and DBIC In-Reply-To: References: Message-ID: Hey, there is a project for Haskell -> Perl using Fay. On Thu, Sep 11, 2014 at 9:13 AM, Mark Tompsett wrote: > Greetings, > > Fey?! Please, let?s not add more technologies (Haskell that compiles to > Javascript) in for geekiness sake. I have been reading this dialogue > between Robin and Kyle and thinking to myself, ?Why was DBIC added in the > first place? Was it not to increase portability (where is that ?it does not > run on Postgresql!? person) , ?simplify? (at the cost of another learning > curve) data access, and provide a cleaner abstraction for data access?? So, > why was it added? Was it added to be more Object Oriented (OO) so we could > use it in the way that is being discussed? So, I?ll reiterate my question > again, which I think will bring some clarity to the discussion, what was > the point of adding DBIC? > > GPML, > Mark Tompsett > P.S. Abstractions are okay, but abstractions upon abstractions are ugly > for the initial learning curve. If you want people to join the coding > community, multiple levels of abstractions make it more difficult. > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -- Tom?s Cohen Arazi Prosecretar?a de Inform?tica Universidad Nacional de C?rdoba ? +54 351 5353750 ext 13168 GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.druart at biblibre.com Mon Sep 15 10:31:13 2014 From: jonathan.druart at biblibre.com (Jonathan Druart) Date: Mon, 15 Sep 2014 10:31:13 +0200 Subject: [Koha-devel] Koha and DBIC In-Reply-To: References: <1410388901.20051.7.camel@zarathud.wgtn.cat-it.co.nz> <1410398389.20051.24.camel@zarathud.wgtn.cat-it.co.nz> <20140911081517.GA3065@zazou.cscnet.co.uk> <035501cfce29$3e013040$ba0390c0$@prosentient.com.au> Message-ID: 2014-09-12 13:47 GMT+02:00 Kyle Hall : >> Koha has a lot of complex concepts. Because it offers a lot of modules >> and possibilities to the users. Koha has to work for every >> configuration across the world. >> Biblio won't be a special case. So there are not reason to cut the >> class in 2 groups: the simple and the complex. >> All lot will need their own modules, because we need to be flexible and >> logical. > > > I absolutely agree. I think at the simplest we can use our Result and > ResultSet classes, at the next level we can extend our Result and ResultSet > classes, and at the far end of the spectrum we have fancy classes that don't > map easily to the database but use DBIC objects to get things done. But we cannot have 2 ways to instantiate an object. I think we should define how we would like to write code using the "new" API. For instance: # Insert a biblio my $biblio = Koha::Biblio->new($biblio_info)->insert (or create) # Delete a biblio my $biblio_2 = Koha::Biblio->fetch($biblionumber)->delete Does everybody agree we want to write something as easy as it? If yes, this should work for all objects. Even if the class if really short (and just tell "this class extends this one"), it should exist. I don't think they should be another way for "simple classes". From arosello at uci.cu Mon Sep 15 14:54:48 2014 From: arosello at uci.cu (Adnier =?utf-8?Q?Rosell=C3=B3?= Carrazana) Date: Mon, 15 Sep 2014 08:54:48 -0400 (CDT) Subject: [Koha-devel] problem to perform a simple query In-Reply-To: <90370813.22738617.1410186095479.JavaMail.zimbra@uci.cu> References: <90370813.22738617.1410186095479.JavaMail.zimbra@uci.cu> Message-ID: <137937855.133677414.1410785688268.JavaMail.zimbra@uci.cu> hi all, I need to know if the search system koha have any character limitation to perform a simple query (without using zebra), I'm doing a search where the record title has 180 characters and the system does not respond so the browser (firefox) closes the connection, thanks for everything, I hope there is some solution, Greetings Concurso "Mi selfie por los 5". Detalles en http://justiciaparaloscinco.wordpress.com From tomascohen at gmail.com Mon Sep 15 20:25:37 2014 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Mon, 15 Sep 2014 15:25:37 -0300 Subject: [Koha-devel] Koha and DBIC In-Reply-To: <1410398389.20051.24.camel@zarathud.wgtn.cat-it.co.nz> References: <1410388901.20051.7.camel@zarathud.wgtn.cat-it.co.nz> <1410398389.20051.24.camel@zarathud.wgtn.cat-it.co.nz> Message-ID: First question to be asked: why are we adopting an ORM? If we are using it to abstract the DB engine selection (i.e. making Koha usable with Postgres instead of only MySQL) I'm sure we are wasting our time. What's the point of rewriting the whole thing to just move away from an enterprise grade DB engine to another? Is it worth the trouble? I'm glad that using an ORM also serves that purpose, but... I think our project is complex enough to benefit from strictly sticking to design patterns, such as the repository pattern; in which the ORM takes care of persistence and nothing more, and we build our business logic on top of that. On that subject, I fully agree with Robin, that we shouldn't rely on hooking the ORM to solve any business logic issue: we need to have our own abstraction layer with a proper API we maintain and unit test (mocked tests, and let integration tests deal with the ORM interaction). Hooking the ORM mixes layers, businesses and problems. That's why it is so hard to write some tests for Koha. Also, our ERD needs some tweaking, to aid maintenance, code simplicity and to support an OO design [1]. For instance, a biblio should definitely have its table, and if biblioitems breaks the design, then we should just merge those tables. I wouldn't implement any hack on the code to preserve that discussed structure. I'd rather spend the time fixing it. So at that level, we should implement the repository pattern, with the following goals: - Consistent API, independent of the DB model (people use our API, no need to know how we built our DB structure). - Separation of concerns between layers (easier to code, easier to test, etc) - Let the ORM take care of DB stuff and use the spare time to talk about cats and food. [2] I'd also like to have a RESTful layer for that API, that should be straightforward to maintain: endpoint routing, authorization layer, call to the right method, output. It is outside the scope of this thread, but a better separation of concerns might make it easier to achieve in a short term. We could the gradually move away from our .pl mess, that contains lots of business logic that doesn't get tested. Best regards Tom?s [1] We've just approved a new coding guideline addition in that sense. [2] I forgot to mention beer. On Wed, Sep 10, 2014 at 10:19 PM, Robin Sheat wrote: > Kyle Hall schreef op wo 10-09-2014 om 20:51 [-0400]: > > > > It's funny, I've been trying to think of an example search to justify > > this and I can't really think of one where we can't use existing > > Result relationships to get our data. Maybe find() and single() are > > really all we need from pl files, but I don't think a hard and fast > > rule against search() is a good idea. > > We'd still be coupling to the data storage schema, which is bad. It's > exactly the same logic that says not to have SQL in the .pl files. > > > > Result and ResultSet are part of the Koha namespace. I also feel that > > Only in the sense that they have Koha:: in the name. They are an API to > the database, and are generated directly from the database schema. They > are not an API that is designed to provide logical access to whatever it > is. > > > you aren't quite correct about how one modules need to know the > > change a present the same interface. I can't count the number of times > > I've added a new parameter to an existing subroutine and had to update > > every function call in many perl files. Now that hashref's are more > > common, it's become less of a problem but it's still a problem that > > exists. > > "It's been broken in the past" isn't a justification for "so we should > keep it broken." As we go to a more OO and thought out method of writing > things (again, especially with the Koha:: stuff), we are moving away > from "here's a hashref with the fields from the biblio table" to "here's > an object that represents a biblio, with accessors and modifiers." We > want more of this, and less things going and talking to the database > themselves. > > > I just don't think this is a entirely valid point. Remember, Result > > and ResultSet methods are no different than methods anywhere else in > > Koha and C4. > > They are totally different. They are much closer to an abstraction of > the database, compared to an abstraction of whatever it is the data is > representing. And the code at the .pl level should be working with > abstractions of data, e.g. "a reserve", or "a biblio with attached > items", not "a set of hashrefs containing a biblio, a biblioitem, and > the associated item records." This latter is what Result/ResultSet > represent. > > In the ES code, I've been keeping this in mind. For example, I can go > (from memory): > > my $it = Koha::Biblio->get_iterator; > while (my $bib = $it->next) { > add_to_index($bib); > } > > which means I don't have to care how they're stored. It also meant that > it took very little work to refactor it to handle authorities, as > everything had the same style of API. ResultSet stuff happened in the > modules, but none of it was exposed to the script that was using those > modules. > > > > Exactly. If you look at my accounts rewrite you'll see I didn't try to > > shoehorn everything into Result and ResultSet. I used a Koha module > > that uses Results and ResultSets in a sane fashion. > > And that's fine. Just not at the .pl level. The job of modules is to put > a sensible abstraction between the storage layer and the user interface > layer. As soon as UI related code can touch the storage layer, you're > violating that principle and causing maintenance headaches for the next > person who comes along. > > > > -- > Robin Sheat > Catalyst IT Ltd. > ? +64 4 803 2204 > GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -- Tom?s Cohen Arazi Prosecretar?a de Inform?tica Universidad Nacional de C?rdoba ? +54 351 5353750 ext 13168 GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.m.hall at gmail.com Mon Sep 15 21:02:49 2014 From: kyle.m.hall at gmail.com (Kyle Hall) Date: Mon, 15 Sep 2014 15:02:49 -0400 Subject: [Koha-devel] Koha and DBIC In-Reply-To: References: <1410388901.20051.7.camel@zarathud.wgtn.cat-it.co.nz> <1410398389.20051.24.camel@zarathud.wgtn.cat-it.co.nz> Message-ID: > > First question to be asked: why are we adopting an ORM? > > If we are using it to abstract the DB engine selection (i.e. making Koha > usable with Postgres instead of only MySQL) I'm sure we are wasting our > time. > What's the point of rewriting the whole thing to just move away from an > enterprise grade DB engine to another? Is it worth the trouble? I'm glad > that using an ORM also serves that purpose, but... > > In the past if not now, there has been concerns about the future of MySQL. I think there has been a strong interest in enabling Koha to use Postgres at the very least. > I think our project is complex enough to benefit from strictly sticking to > design patterns, such as the repository pattern; in which the ORM takes > care of persistence and nothing more, and we build our business logic on > top of that. On that subject, I fully agree with Robin, that we shouldn't > rely on hooking the ORM to solve any business logic issue: we need to have > our own abstraction layer with a proper API we maintain and unit test > (mocked tests, and let integration tests deal with the ORM interaction). > Hooking the ORM mixes layers, businesses and problems. That's why it is so > hard to write some tests for Koha. > I can totally agree with this, except I don't see where we are using any design patterns with Koha. I we need to retain the pattern of Objects and Object Sets. But we already have those though DBIC! In the end we could easily yank out DBIC and replace it with something else so long as it provides the same methods ( create, update, delete, find, search, etc ). I am troubled by the idea that we should wrap all our dbic classes in yet more classes. Every example I've seen of this has more code by a factor of almost 10. I don't know if Koha is so complex that it requires a repository pattern. Look at this example: http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=31607&action=diff#a/Koha/Schema/ResultSet/Reserve.pm_sec1 How much more difficult will this be for developers, and how much more overhead will it require if we wrap our objects in more objects? We'd have to fetch the Row objects, wrap them in KohaRow objects, wrap those in a KohaRowSet, and return them. Certainly, but far more complicated. That being said, if the majority agree, than I will be the first to jump aboard. However, there have definitely been others who are reticent as well. > > Also, our ERD needs some tweaking, to aid maintenance, code simplicity and > to support an OO design [1]. For instance, a biblio should definitely have > its table, and if biblioitems breaks the design, then we should just merge > those tables. I wouldn't implement any hack on the code to preserve that > discussed structure. I'd rather spend the time fixing it. > I totally agree. The biblio and biblioitems tables need to be merged. Finding a volunteer will be the hard part! > > So at that level, we should implement the repository pattern, with the > following goals: > - Consistent API, independent of the DB model (people use our API, no need > to know how we built our DB structure). > Is this so other software can make use of Koha's functions and methods? > - Separation of concerns between layers (easier to code, easier to test, > etc) > I will concede that unit testing would be much easier if we could instantiate objects and object sets without using the database. It *is* trivial to create Result objects without touching the db, but ResultSets are another matter. However, it seems like it may be possible: http://modernperlbooks.com/mt/2011/05/testing-dbix-models-without-the-database.html > - Let the ORM take care of DB stuff and use the spare time to talk about > cats and food. [2] > Don't forget about dogs! We've got plenty of dog lovers in out community ; ) > > I'd also like to have a RESTful layer for that API, that should be > straightforward to maintain: endpoint routing, authorization layer, call to > the right method, output. It is outside the scope of this thread, but a > better separation of concerns might make it easier to achieve in a short > term. We could the gradually move away from our .pl mess, that contains > lots of business logic that doesn't get tested. > This I completely agree with. I think all outside systems should interact with Koha though a well designed restful interface. I'm hoping to get started on this soon. Jesse Weaver has already written some great code I can use as a start. Kyle -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.de.Rooy at rijksmuseum.nl Mon Sep 15 21:11:35 2014 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Mon, 15 Sep 2014 19:11:35 +0000 Subject: [Koha-devel] Koha and DBIC In-Reply-To: References: <1410388901.20051.7.camel@zarathud.wgtn.cat-it.co.nz> <1410398389.20051.24.camel@zarathud.wgtn.cat-it.co.nz> , Message-ID: <809BE39CD64BFD4EB9036172EBCCFA31423D34C8@S-MAIL-1B.rijksmuseum.intra> > I am troubled by the idea that we should wrap all our dbic classes in yet more classes. Every example I've seen of this has more code by a factor of almost 10. I don't know if Koha is so complex that it requires a repository pattern. I think that it would require rewriting Koha. This changeover might just be too complex for us. > How much more difficult will this be for developers, and how much more overhead will it require if we wrap our objects in more objects? We'd have to fetch the Row objects, wrap them in KohaRow objects, wrap those in a KohaRowSet, and return them. Certainly, but far more complicated. I would say: Leave all storage related actions in Koha::Schema. KohaRow does not make sense to me. Furthermore, define the objects that actually have 'real' business logic and put that in some Koha::Object. Marcel -------------- next part -------------- An HTML attachment was scrubbed... URL: From robin at catalyst.net.nz Tue Sep 16 01:26:54 2014 From: robin at catalyst.net.nz (Robin Sheat) Date: Tue, 16 Sep 2014 11:26:54 +1200 Subject: [Koha-devel] problem to perform a simple query In-Reply-To: <137937855.133677414.1410785688268.JavaMail.zimbra@uci.cu> References: <90370813.22738617.1410186095479.JavaMail.zimbra@uci.cu> <137937855.133677414.1410785688268.JavaMail.zimbra@uci.cu> Message-ID: <1410823613.20051.38.camel@zarathud.wgtn.cat-it.co.nz> Adnier Rosell? Carrazana schreef op ma 15-09-2014 om 08:54 [-0400]: > I need to know if the search system koha have any character limitation > to perform a simple query (without using zebra) What do you mean "without using zebra"? There shouldn't be an option to not use zebra any more. -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part URL: From psm_vu at india.com Tue Sep 16 10:15:55 2014 From: psm_vu at india.com (Partha Mukhopadhyay) Date: Tue, 16 Sep 2014 08:15:55 +0000 (UTC) Subject: [Koha-devel] VIAF and Koha 3.16.x Message-ID: <1466111020.197668.1410855355242.JavaMail.tomcat@be02> An HTML attachment was scrubbed... URL: From arosello at uci.cu Tue Sep 16 22:15:13 2014 From: arosello at uci.cu (Adnier =?utf-8?Q?Rosell=C3=B3?= Carrazana) Date: Tue, 16 Sep 2014 16:15:13 -0400 (CDT) Subject: [Koha-devel] problem to perform a simple query (Adnier Rosello) In-Reply-To: References: Message-ID: <1412455981.134123159.1410898513042.JavaMail.zimbra@uci.cu> Robin: apology not specify in my previous mail that my koha version is 3.0.6, which has a preference variable to not use the zebra (NoZebra), so the search of bibliographic records are handled directly by MySQL, grateful by the response, I hope to clarify the problem, Greetings Ad ----- Mensaje original ----- Send Koha-devel mailing list submissions to koha-devel at 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 at lists.koha-community.org You can reach the person managing the list at koha-devel-owner at 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: Koha and DBIC (Marcel de Rooy) 2. Re: problem to perform a simple query (Robin Sheat) 3. VIAF and Koha 3.16.x (Partha Mukhopadhyay) ---------------------------------------------------------------------- Message: 1 Date: Mon, 15 Sep 2014 19:11:35 +0000 From: Marcel de Rooy To: Koha Devel Subject: Re: [Koha-devel] Koha and DBIC Message-ID: <809BE39CD64BFD4EB9036172EBCCFA31423D34C8 at S-MAIL-1B.rijksmuseum.intra> Content-Type: text/plain; charset="iso-8859-1" > I am troubled by the idea that we should wrap all our dbic classes in yet more classes. Every example I've seen of this has more code by a factor of almost 10. I don't know if Koha is so complex that it requires a repository pattern. I think that it would require rewriting Koha. This changeover might just be too complex for us. > How much more difficult will this be for developers, and how much more overhead will it require if we wrap our objects in more objects? We'd have to fetch the Row objects, wrap them in KohaRow objects, wrap those in a KohaRowSet, and return them. Certainly, but far more complicated. I would say: Leave all storage related actions in Koha::Schema. KohaRow does not make sense to me. Furthermore, define the objects that actually have 'real' business logic and put that in some Koha::Object. Marcel -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Tue, 16 Sep 2014 11:26:54 +1200 From: Robin Sheat To: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] problem to perform a simple query Message-ID: <1410823613.20051.38.camel at zarathud.wgtn.cat-it.co.nz> Content-Type: text/plain; charset="utf-8" Adnier Rosell? Carrazana schreef op ma 15-09-2014 om 08:54 [-0400]: > I need to know if the search system koha have any character limitation > to perform a simple query (without using zebra) What do you mean "without using zebra"? There shouldn't be an option to not use zebra any more. -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part URL: ------------------------------ Message: 3 Date: Tue, 16 Sep 2014 08:15:55 +0000 (UTC) From: Partha Mukhopadhyay To: koha-devel at lists.koha-community.org Subject: [Koha-devel] VIAF and Koha 3.16.x Message-ID: <1466111020.197668.1410855355242.JavaMail.tomcat at be02> Content-Type: text/plain; charset="us-ascii" An HTML attachment was scrubbed... URL: ------------------------------ _______________________________________________ Koha-devel mailing list Koha-devel at 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/ End of Koha-devel Digest, Vol 106, Issue 19 ******************************************* Concurso "Mi selfie por los 5". Detalles en http://justiciaparaloscinco.wordpress.com From francois.charbonnier at inlibro.com Tue Sep 16 16:55:57 2014 From: francois.charbonnier at inlibro.com (Francois Charbonnier) Date: Tue, 16 Sep 2014 10:55:57 -0400 Subject: [Koha-devel] Dom indexing operational with a fresh install? Message-ID: <54184F7D.209@inlibro.com> Hello, Yesterday, I bumped into an indexing bug. The 008 language code is not indexed. I can't find the records using this value. I checked on bugzilla and found this old bug : http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7586. This bug changed "ln:n" by "ln:w" in record.abs . It works with grs-1 indexing. On Katrin advice, I checked if the installation is using dom or grs-1 indexing. I'm on 3.14.07. So it should use dom. koha-conf.xml says "dom" but zebra-biblios.cfg seems to say "grs"... So, I checked "zebra-biblios.cfg" on master and the default values are : * iso2709.recordType:grs.marcxml.record * marcxml.recordType:grs.sgml * recordType:grs.xml Shouldn't we have a reference to dom for these parameters? I also checked biblio-zebra-indexdefs.xsl and biblio-koha-indexdefs.xml and the language index is "ln:n". I tried to change it by "ln:w", restarted zebra server, reindexed but it didn't work. I followed the wiki instruction (http://wiki.koha-community.org/wiki/Switching_to_dom_indexing) to change the "zebra-biblios.cfg" values as well but didn't work either. Any ideas? Thanks! -- Fran?ois Charbonnier, Bibl. prof. / Chef de produits T?l. : (888) 604-2627 francois.charbonnier at inLibro.com inLibro | pour esprit libre | www.inLibro.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomascohen at gmail.com Wed Sep 17 00:29:13 2014 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Tue, 16 Sep 2014 19:29:13 -0300 Subject: [Koha-devel] Dom indexing operational with a fresh install? In-Reply-To: <54184F7D.209@inlibro.com> References: <54184F7D.209@inlibro.com> Message-ID: On Tue, Sep 16, 2014 at 11:55 AM, Francois Charbonnier < francois.charbonnier at inlibro.com> wrote: > > Hello, > > Yesterday, I bumped into an indexing bug. The 008 language code is not indexed. I can't find the records using this value. I checked on bugzilla and found this old bug : http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7586. This bug changed "ln:n" by "ln:w" in record.abs . > > It works with grs-1 indexing. On Katrin advice, I checked if the installation is using dom or grs-1 indexing. > > I'm on 3.14.07. So it should use dom. koha-conf.xml says "dom" but zebra-biblios.cfg seems to say "grs"... Your koha-conf.xml file should be pointing to zebra-biblios-dom.cfg in the id="biblioserver" section. Best regards To+ -- Tom?s Cohen Arazi Prosecretar?a de Inform?tica Universidad Nacional de C?rdoba ? +54 351 5353750 ext 13168 GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.m.hall at gmail.com Tue Sep 16 13:16:18 2014 From: kyle.m.hall at gmail.com (Kyle Hall) Date: Tue, 16 Sep 2014 07:16:18 -0400 Subject: [Koha-devel] Koha and DBIC In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA31423D34C8@S-MAIL-1B.rijksmuseum.intra> References: <1410388901.20051.7.camel@zarathud.wgtn.cat-it.co.nz> <1410398389.20051.24.camel@zarathud.wgtn.cat-it.co.nz> <809BE39CD64BFD4EB9036172EBCCFA31423D34C8@S-MAIL-1B.rijksmuseum.intra> Message-ID: Yes. I'm imagining something along the lines of Koha::Object, and Koha::Object::Set which would have all the boilerplate we need for general use ( get, set, find, search, etc ). Then all our table-tied objects would inherit from Koha::Object and a set of those objects would inherit from Koha::Object::Set. Both of those classes can be DBIC-aware internally. Internally Koha::Object would have a DBIC Result as a property, which can be used independently from the database ( which would be good for unit testing ). Each Koha::Object::Set would normally keep only a ResultSet internally and work on that until asked to return a Koha::Object, at which point it would wrap each Result in a Koha::Object and store them internally, or return an array of them depending on what type of return value the method was called with. I would be willing to write up Koha::Object and Koha::Object::Set if this is what Robin, Tomas et. al. are looking for. In this way we have DBIC totally encapsulated so the code using Koha::Object and Koha::Object::Set's is totally DBIC unaware but internally is DBIC aware. In addition, if we have these two classes to inherit from, it will reduce the amount of code we must write, and make it much easier for new developers. One we have Object and Object::Set written, we don't have to rewrite our CRUD boilerplate for each and every new class we add. What do you think? Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) On Mon, Sep 15, 2014 at 3:11 PM, Marcel de Rooy wrote: > > I am troubled by the idea that we should wrap all our dbic classes in > yet more classes. Every example I've seen of this has more code by a factor > of almost 10. I don't know if Koha is so complex that it requires a > repository pattern. > I think that it would require rewriting Koha. This changeover might > just be too complex for us. > > > How much more difficult will this be for developers, and how much more > overhead will it require if we wrap our objects in more objects? We'd have > to fetch the Row objects, wrap them in KohaRow objects, wrap those in a > KohaRowSet, and return them. Certainly, but far more complicated. > I would say: Leave all storage related actions in Koha::Schema. KohaRow > does not make sense to me. > Furthermore, define the objects that actually have 'real' business logic > and put that in some Koha::Object. > > Marcel > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bargioni at pusc.it Tue Sep 16 15:50:16 2014 From: bargioni at pusc.it (Stefano Bargioni) Date: Tue, 16 Sep 2014 15:50:16 +0200 Subject: [Koha-devel] VIAF and Koha 3.16.x In-Reply-To: <1466111020.197668.1410855355242.JavaMail.tomcat@be02> References: <1466111020.197668.1410855355242.JavaMail.tomcat@be02> Message-ID: Yep, you are right. I'll try to fix it ASAP, even if I'm not running 3.16 yet. Stefano On 16/set/2014, at 10:15, Partha Mukhopadhyay wrote: > Attention!!! Stefano Bargioni > > The JQuery script (http://wiki.koha-community.org/wiki/JQuery_Library#Add_VIAF_autosuggest_for_new_NAME_authorities) for integrating Koha with VIAF is not working in Koha 3.16.x (tested from 3.16.1 to 3.16.3). > ---------------------------------------------------- > > Dr. Parthasarathi Mukhopadhyay > > Associate Professor > > Department of Library and Information Science > > University of Kalyani (WB, India) > > ------------------------------------------ > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleonard at myacpl.org Tue Sep 16 15:41:11 2014 From: oleonard at myacpl.org (Owen Leonard) Date: Tue, 16 Sep 2014 09:41:11 -0400 Subject: [Koha-devel] Reminder: Koha Developer IRC meeting 16 September 2014 at 15:00 and 22:00 UTC Message-ID: There are two developer meetings today: 16 September 2014, 15UTC http://www.timeanddate.com/worldclock/fixedtime.html?msg=Koha+Developers+IRC+Meeting&iso=20140916T15 16 September 2014, 22UTC http://www.timeanddate.com/worldclock/fixedtime.html?msg=Koha+Developers+IRC+Meeting&iso=20140916T22 The agenda is here: http://wiki.koha-community.org/wiki/Development_IRC_meeting,_16_September_2014 I hope you can make it, Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From robin at catalyst.net.nz Wed Sep 17 03:12:34 2014 From: robin at catalyst.net.nz (Robin Sheat) Date: Wed, 17 Sep 2014 13:12:34 +1200 Subject: [Koha-devel] problem to perform a simple query (Adnier Rosello) In-Reply-To: <1412455981.134123159.1410898513042.JavaMail.zimbra@uci.cu> References: <1412455981.134123159.1410898513042.JavaMail.zimbra@uci.cu> Message-ID: <1410916354.20051.45.camel@zarathud.wgtn.cat-it.co.nz> Adnier Rosell? Carrazana schreef op di 16-09-2014 om 16:15 [-0400]: > apology not specify in my previous mail that my koha version is 3.0.6, > which has a preference variable to not use the zebra (NoZebra), so the > search of bibliographic records are handled directly by MySQL, > grateful by the response, I hope to clarify the problem, Greetings 3.0.6 was released in May 2010, it's over four years old and very much unsupported. The NoZebra configuration is also not well supported and has been removed from later versions. I'd suggest upgrading to a current version of Koha and using Zebra. Things are then more likely to work. -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF From Holger.Meissner at hs-gesundheit.de Wed Sep 17 07:32:21 2014 From: Holger.Meissner at hs-gesundheit.de (Holger Meissner) Date: Wed, 17 Sep 2014 05:32:21 +0000 Subject: [Koha-devel] Rebase after passing QA? Message-ID: <2C614FEEE2356A428DC65441E30302E0010048A7A5@nero> Dear Koha devs, a few weeks ago one of my patches passed QA. By now it doesn't auto-merge with master anymore. I suspect the conflicts can be resolved without too much trouble. Should I rebase, keeping the Passed QA status? Or should I rebase and set back to Signed Off? Or leave it to the RM to rebase? Thanks Holger From chrisc at catalyst.net.nz Wed Sep 17 08:11:14 2014 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Wed, 17 Sep 2014 18:11:14 +1200 Subject: [Koha-devel] Rebase after passing QA? In-Reply-To: <2C614FEEE2356A428DC65441E30302E0010048A7A5@nero> References: <2C614FEEE2356A428DC65441E30302E0010048A7A5@nero> Message-ID: <20140917061114.GB5376@rorohiko.wgtn.cat-it.co.nz> * Holger Meissner (Holger.Meissner at hs-gesundheit.de) wrote: > Dear Koha devs, > > a few weeks ago one of my patches passed QA. By now it doesn't auto-merge with master anymore. I suspect the conflicts can be resolved without too much trouble. Should I rebase, keeping the Passed QA status? Or should I rebase and set back to Signed Off? Or leave it to the RM to rebase? > Id rebase it, and if it is only a tiny conflict, leave it as passed qa, if its a big one, then I'd ask Tomas what he would like you to do. Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From jonathan.druart at biblibre.com Wed Sep 17 09:24:25 2014 From: jonathan.druart at biblibre.com (Jonathan Druart) Date: Wed, 17 Sep 2014 09:24:25 +0200 Subject: [Koha-devel] Koha and DBIC In-Reply-To: References: <1410388901.20051.7.camel@zarathud.wgtn.cat-it.co.nz> <1410398389.20051.24.camel@zarathud.wgtn.cat-it.co.nz> <809BE39CD64BFD4EB9036172EBCCFA31423D34C8@S-MAIL-1B.rijksmuseum.intra> Message-ID: \o/ If I understood correctly, it's exactly what I had in mind, so I totally agree! 2014-09-16 13:16 GMT+02:00 Kyle Hall : > Yes. I'm imagining something along the lines of Koha::Object, and > Koha::Object::Set which would have all the boilerplate we need for general > use ( get, set, find, search, etc ). Then all our table-tied objects would > inherit from Koha::Object and a set of those objects would inherit from > Koha::Object::Set. Both of those classes can be DBIC-aware internally. > > Internally Koha::Object would have a DBIC Result as a property, which can be > used independently from the database ( which would be good for unit testing > ). Each Koha::Object::Set would normally keep only a ResultSet internally > and work on that until asked to return a Koha::Object, at which point it > would wrap each Result in a Koha::Object and store them internally, or > return an array of them depending on what type of return value the method > was called with. > > I would be willing to write up Koha::Object and Koha::Object::Set if this is > what Robin, Tomas et. al. are looking for. > > In this way we have DBIC totally encapsulated so the code using Koha::Object > and Koha::Object::Set's is totally DBIC unaware but internally is DBIC > aware. > > In addition, if we have these two classes to inherit from, it will reduce > the amount of code we must write, and make it much easier for new > developers. One we have Object and Object::Set written, we don't have to > rewrite our CRUD boilerplate for each and every new class we add. > > What do you think? > > Kyle > > http://www.kylehall.info > ByWater Solutions ( http://bywatersolutions.com ) > Meadville Public Library ( http://www.meadvillelibrary.org ) > Crawford County Federated Library System ( http://www.ccfls.org ) > Mill Run Technology Solutions ( http://millruntech.com ) > > On Mon, Sep 15, 2014 at 3:11 PM, Marcel de Rooy > wrote: >> >> > I am troubled by the idea that we should wrap all our dbic classes in >> > yet more classes. Every example I've seen of this has more code by a factor >> > of almost 10. I don't know if Koha is so complex that it requires a >> > repository pattern. >> I think that it would require rewriting Koha. This changeover might just >> be too complex for us. >> >> > How much more difficult will this be for developers, and how much more >> > overhead will it require if we wrap our objects in more objects? We'd have >> > to fetch the Row objects, wrap them in KohaRow objects, wrap those in a >> > KohaRowSet, and return them. Certainly, but far more complicated. >> I would say: Leave all storage related actions in Koha::Schema. KohaRow >> does not make sense to me. >> Furthermore, define the objects that actually have 'real' business logic >> and put that in some Koha::Object. >> >> Marcel >> >> _______________________________________________ >> Koha-devel mailing list >> Koha-devel at 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/ > > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ From chrisc at catalyst.net.nz Wed Sep 17 09:50:42 2014 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Wed, 17 Sep 2014 19:50:42 +1200 Subject: [Koha-devel] Koha and DBIC In-Reply-To: References: <1410388901.20051.7.camel@zarathud.wgtn.cat-it.co.nz> <1410398389.20051.24.camel@zarathud.wgtn.cat-it.co.nz> <809BE39CD64BFD4EB9036172EBCCFA31423D34C8@S-MAIL-1B.rijksmuseum.intra> Message-ID: <20140917075041.GC5376@rorohiko.wgtn.cat-it.co.nz> * Jonathan Druart (jonathan.druart at biblibre.com) wrote: > \o/ > If I understood correctly, it's exactly what I had in mind, so I totally agree! > > 2014-09-16 13:16 GMT+02:00 Kyle Hall : > > Yes. I'm imagining something along the lines of Koha::Object, and > > Koha::Object::Set which would have all the boilerplate we need for general > > use ( get, set, find, search, etc ). Then all our table-tied objects would > > inherit from Koha::Object and a set of those objects would inherit from > > Koha::Object::Set. Both of those classes can be DBIC-aware internally. > > > > Internally Koha::Object would have a DBIC Result as a property, which can be > > used independently from the database ( which would be good for unit testing > > ). Each Koha::Object::Set would normally keep only a ResultSet internally > > and work on that until asked to return a Koha::Object, at which point it > > would wrap each Result in a Koha::Object and store them internally, or > > return an array of them depending on what type of return value the method > > was called with. > > > > I would be willing to write up Koha::Object and Koha::Object::Set if this is > > what Robin, Tomas et. al. are looking for. > > > > In this way we have DBIC totally encapsulated so the code using Koha::Object > > and Koha::Object::Set's is totally DBIC unaware but internally is DBIC > > aware. > > > > In addition, if we have these two classes to inherit from, it will reduce > > the amount of code we must write, and make it much easier for new > > developers. One we have Object and Object::Set written, we don't have to > > rewrite our CRUD boilerplate for each and every new class we add. > > > > What do you think? > > > > Kyle > > I cant answer for Tomas or Robin, but this is not what I was thinking at all. We don't need more boilerplate setters and getters, DBIX::Class does this for us. What we don't want, is DBIx::Class or for that matter Koha::Object calls in the .pl files I dont think we need to build an abstraction over DBIx::Class, certainly thats not what Robin was asking. What we don't want to see is DBIx::Class calls in the .pl files they should live in modules (objects) in the Koha:: namespace. In fact all of our pl files that are longer than about 40 lines should all be rewritten, all the business logic should be in the modules. I think there may be a misunderstanding, we dont need to abstract database access over top of DBIx::Class .. thats what it's for. What we dont want to be doing is setting and getting from inside the pl files. I think if you look at the Koha::Biblio modules etc that Robin has written they illustrate this. Hopefully this is clear, to restate -1 for DBIx::Class calls in the .pl -1 for Koha::Object and Koha::Object::Set +1 for proper objects like Koha::Biblio, Koha::Account, Koha::Serial etc Chris > > http://www.kylehall.info > > ByWater Solutions ( http://bywatersolutions.com ) > > Meadville Public Library ( http://www.meadvillelibrary.org ) > > Crawford County Federated Library System ( http://www.ccfls.org ) > > Mill Run Technology Solutions ( http://millruntech.com ) > > > > On Mon, Sep 15, 2014 at 3:11 PM, Marcel de Rooy > > wrote: > >> > >> > I am troubled by the idea that we should wrap all our dbic classes in > >> > yet more classes. Every example I've seen of this has more code by a factor > >> > of almost 10. I don't know if Koha is so complex that it requires a > >> > repository pattern. > >> I think that it would require rewriting Koha. This changeover might just > >> be too complex for us. > >> > >> > How much more difficult will this be for developers, and how much more > >> > overhead will it require if we wrap our objects in more objects? We'd have > >> > to fetch the Row objects, wrap them in KohaRow objects, wrap those in a > >> > KohaRowSet, and return them. Certainly, but far more complicated. > >> I would say: Leave all storage related actions in Koha::Schema. KohaRow > >> does not make sense to me. > >> Furthermore, define the objects that actually have 'real' business logic > >> and put that in some Koha::Object. > >> > >> Marcel > >> > >> _______________________________________________ > >> Koha-devel mailing list > >> Koha-devel at 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/ > > > > > > > > _______________________________________________ > > Koha-devel mailing list > > Koha-devel at 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/ > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From jonathan.druart at biblibre.com Wed Sep 17 10:32:23 2014 From: jonathan.druart at biblibre.com (Jonathan Druart) Date: Wed, 17 Sep 2014 10:32:23 +0200 Subject: [Koha-devel] Koha and DBIC In-Reply-To: <20140917075041.GC5376@rorohiko.wgtn.cat-it.co.nz> References: <1410388901.20051.7.camel@zarathud.wgtn.cat-it.co.nz> <1410398389.20051.24.camel@zarathud.wgtn.cat-it.co.nz> <809BE39CD64BFD4EB9036172EBCCFA31423D34C8@S-MAIL-1B.rijksmuseum.intra> <20140917075041.GC5376@rorohiko.wgtn.cat-it.co.nz> Message-ID: Chris, I tent to agree with you, but a Koha::Object makes sense to me. For instance, bug 12891 [1] shows us that we need an object to refactor common stuffs. [1] http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=31515 2014-09-17 9:50 GMT+02:00 Chris Cormack : > * Jonathan Druart (jonathan.druart at biblibre.com) wrote: >> \o/ >> If I understood correctly, it's exactly what I had in mind, so I totally agree! >> >> 2014-09-16 13:16 GMT+02:00 Kyle Hall : >> > Yes. I'm imagining something along the lines of Koha::Object, and >> > Koha::Object::Set which would have all the boilerplate we need for general >> > use ( get, set, find, search, etc ). Then all our table-tied objects would >> > inherit from Koha::Object and a set of those objects would inherit from >> > Koha::Object::Set. Both of those classes can be DBIC-aware internally. >> > >> > Internally Koha::Object would have a DBIC Result as a property, which can be >> > used independently from the database ( which would be good for unit testing >> > ). Each Koha::Object::Set would normally keep only a ResultSet internally >> > and work on that until asked to return a Koha::Object, at which point it >> > would wrap each Result in a Koha::Object and store them internally, or >> > return an array of them depending on what type of return value the method >> > was called with. >> > >> > I would be willing to write up Koha::Object and Koha::Object::Set if this is >> > what Robin, Tomas et. al. are looking for. >> > >> > In this way we have DBIC totally encapsulated so the code using Koha::Object >> > and Koha::Object::Set's is totally DBIC unaware but internally is DBIC >> > aware. >> > >> > In addition, if we have these two classes to inherit from, it will reduce >> > the amount of code we must write, and make it much easier for new >> > developers. One we have Object and Object::Set written, we don't have to >> > rewrite our CRUD boilerplate for each and every new class we add. >> > >> > What do you think? >> > >> > Kyle >> > > > I cant answer for Tomas or Robin, but this is not what I was thinking at all. > We don't need more boilerplate setters and getters, DBIX::Class does this for us. > > What we don't want, is DBIx::Class or for that matter Koha::Object calls in the .pl files > > I dont think we need to build an abstraction over DBIx::Class, certainly thats > not what Robin was asking. What we don't want to see is DBIx::Class calls in the .pl files > they should live in modules (objects) in the Koha:: namespace. > > In fact all of our pl files that are longer than about 40 lines should all be > rewritten, all the business logic should be in the modules. > > I think there may be a misunderstanding, we dont need to abstract database > access over top of DBIx::Class .. thats what it's for. What we dont want to be doing > is setting and getting from inside the pl files. > > I think if you look at the Koha::Biblio modules etc that Robin has written > they illustrate this. > > Hopefully this is clear, to restate > > -1 for DBIx::Class calls in the .pl > -1 for Koha::Object and Koha::Object::Set > +1 for proper objects like Koha::Biblio, Koha::Account, Koha::Serial etc > > Chris > > > >> > http://www.kylehall.info >> > ByWater Solutions ( http://bywatersolutions.com ) >> > Meadville Public Library ( http://www.meadvillelibrary.org ) >> > Crawford County Federated Library System ( http://www.ccfls.org ) >> > Mill Run Technology Solutions ( http://millruntech.com ) >> > >> > On Mon, Sep 15, 2014 at 3:11 PM, Marcel de Rooy >> > wrote: >> >> >> >> > I am troubled by the idea that we should wrap all our dbic classes in >> >> > yet more classes. Every example I've seen of this has more code by a factor >> >> > of almost 10. I don't know if Koha is so complex that it requires a >> >> > repository pattern. >> >> I think that it would require rewriting Koha. This changeover might just >> >> be too complex for us. >> >> >> >> > How much more difficult will this be for developers, and how much more >> >> > overhead will it require if we wrap our objects in more objects? We'd have >> >> > to fetch the Row objects, wrap them in KohaRow objects, wrap those in a >> >> > KohaRowSet, and return them. Certainly, but far more complicated. >> >> I would say: Leave all storage related actions in Koha::Schema. KohaRow >> >> does not make sense to me. >> >> Furthermore, define the objects that actually have 'real' business logic >> >> and put that in some Koha::Object. >> >> >> >> Marcel >> >> >> >> _______________________________________________ >> >> Koha-devel mailing list >> >> Koha-devel at 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/ >> > >> > >> > >> > _______________________________________________ >> > Koha-devel mailing list >> > Koha-devel at 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/ >> _______________________________________________ >> Koha-devel mailing list >> Koha-devel at 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/ > > -- > Chris Cormack > Catalyst IT Ltd. > +64 4 803 2238 > PO Box 11-053, Manners St, Wellington 6142, New Zealand From kyle.m.hall at gmail.com Wed Sep 17 12:40:09 2014 From: kyle.m.hall at gmail.com (Kyle Hall) Date: Wed, 17 Sep 2014 06:40:09 -0400 Subject: [Koha-devel] Koha and DBIC In-Reply-To: <20140917075041.GC5376@rorohiko.wgtn.cat-it.co.nz> References: <1410388901.20051.7.camel@zarathud.wgtn.cat-it.co.nz> <1410398389.20051.24.camel@zarathud.wgtn.cat-it.co.nz> <809BE39CD64BFD4EB9036172EBCCFA31423D34C8@S-MAIL-1B.rijksmuseum.intra> <20140917075041.GC5376@rorohiko.wgtn.cat-it.co.nz> Message-ID: Chris, I'm a bit lost here. The idea behind Koha::Object is that we have a common base class from which to derive Koha::Biblio, Koha::Serial and so forth. That is, this class would be used as the base for classes that have a simple 1 to 1 table mapping to encapsulate DBIC while maintaining a consistent set of methods across our many classes. ObjectSet would give us set iterators, set operations, and be a better place to have methods that return a set ( e.g. Koha::Issue::Set::GetOverdues would return a collection of overdue checkouts ). I'm not sure why you disagree with this idea. Could you expand a bit? Kyle > -1 for DBIx::Class calls in the .pl > -1 for Koha::Object and Koha::Object::Set > +1 for proper objects like Koha::Biblio, Koha::Account, Koha::Serial etc > > Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From colin.campbell at ptfs-europe.com Wed Sep 17 12:49:23 2014 From: colin.campbell at ptfs-europe.com (Colin Campbell) Date: Wed, 17 Sep 2014 11:49:23 +0100 Subject: [Koha-devel] Koha and DBIC In-Reply-To: References: <1410388901.20051.7.camel@zarathud.wgtn.cat-it.co.nz> <1410398389.20051.24.camel@zarathud.wgtn.cat-it.co.nz> <809BE39CD64BFD4EB9036172EBCCFA31423D34C8@S-MAIL-1B.rijksmuseum.intra> <20140917075041.GC5376@rorohiko.wgtn.cat-it.co.nz> Message-ID: <20140917104923.GA7912@zazou.cscnet.co.uk> A Koha::Object sounds like extremely poor design. What kind of object is a Koha::Object, what are its properties, when we say a Koha::Biblio isa Koha::Object what does that mean? In practice what meaningful properties it has it inherits from Koha::Schema::Result::Biblio which is liable to be a better representation than the vaguer Onject. In practice I've recently written some scripts which in first version used some abstractions built around dbic ResultSets, As I added to them I stripped out out the abstractions and used the dbic result sets as I found this generated cleaner, more straightforward code. Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 800 756 6803 (phone) +44 (0) 7759 633626 (mobile) colin.campbell at ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com From M.de.Rooy at rijksmuseum.nl Wed Sep 17 14:40:51 2014 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Wed, 17 Sep 2014 12:40:51 +0000 Subject: [Koha-devel] Koha and DBIC In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA31423D34C8@S-MAIL-1B.rijksmuseum.intra> References: <1410388901.20051.7.camel@zarathud.wgtn.cat-it.co.nz> <1410398389.20051.24.camel@zarathud.wgtn.cat-it.co.nz> , , <809BE39CD64BFD4EB9036172EBCCFA31423D34C8@S-MAIL-1B.rijksmuseum.intra> Message-ID: <809BE39CD64BFD4EB9036172EBCCFA31423D7E05@S-MAIL-1B.rijksmuseum.intra> > I would say: Leave all storage related actions in Koha::Schema. KohaRow does not make sense to me. > Furthermore, define the objects that actually have 'real' business logic and put that in some Koha::Object. Just to add to the confusion ;) When I wrote "some Koha::Object" here, I was not literally suggesting Koha::Object, I was thinking of something like Koha::Biblio or Koha::Patron etc. I would not suggest to add such an object for every table in Koha. We should clearly define which objects(!) we really need, having sufficient business logic etc. to justify an interface to DBIx. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00001.txt URL: From mtompset at hotmail.com Wed Sep 17 14:50:37 2014 From: mtompset at hotmail.com (Mark Tompsett) Date: Wed, 17 Sep 2014 08:50:37 -0400 Subject: [Koha-devel] Koha and DBIC In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA31423D7E05@S-MAIL-1B.rijksmuseum.intra> References: <1410388901.20051.7.camel@zarathud.wgtn.cat-it.co.nz><1410398389.20051.24.camel@zarathud.wgtn.cat-it.co.nz>, , <809BE39CD64BFD4EB9036172EBCCFA31423D34C8@S-MAIL-1B.rijksmuseum.intra> <809BE39CD64BFD4EB9036172EBCCFA31423D7E05@S-MAIL-1B.rijksmuseum.intra> Message-ID: Greetings, > Just to add to the confusion ;) > When I wrote "some Koha::Object" here, > I was not literally suggesting Koha::Object, > I was thinking of something like Koha::Biblio or Koha::Patron etc. That?s what I understood. So physically, we may have the tables we currently have accessed via DBIC, but the Koha::Biblio object would blend DBIC objects related to Biblios and Items. Right? This would mean that Koha::Biblio would provide whatever methods regardless of the backend structure. GPML, Mark Tompsett -------------- next part -------------- An HTML attachment was scrubbed... URL: From colin.campbell at ptfs-europe.com Wed Sep 17 15:49:34 2014 From: colin.campbell at ptfs-europe.com (Colin Campbell) Date: Wed, 17 Sep 2014 14:49:34 +0100 Subject: [Koha-devel] Koha and DBIC In-Reply-To: References: <1410388901.20051.7.camel@zarathud.wgtn.cat-it.co.nz> <1410398389.20051.24.camel@zarathud.wgtn.cat-it.co.nz> <809BE39CD64BFD4EB9036172EBCCFA31423D34C8@S-MAIL-1B.rijksmuseum.intra> <809BE39CD64BFD4EB9036172EBCCFA31423D7E05@S-MAIL-1B.rijksmuseum.intra> Message-ID: <20140917134934.GA10248@zazou.cscnet.co.uk> On Wed, Sep 17, 2014 at 08:50:37AM -0400, Mark Tompsett wrote: > Greetings, > > > Just to add to the confusion ;) > > When I wrote "some Koha::Object" here, > > I was not literally suggesting Koha::Object, > > I was thinking of something like Koha::Biblio or Koha::Patron etc. > That?s what I understood. So physically, we may have the tables we currently have accessed via DBIC, but the Koha::Biblio object would blend DBIC objects related to Biblios and Items. Right? This would mean that Koha::Biblio would provide whatever methods regardless of the backend structure. Trouble is it sidesteps fixing the schema. The interplay between biblio and biblioitems will remain a problem for maintenance in future. There is already special code added to link the classes because their relationship is not maintained by the database. Special cases tend to grow over time and spawn more special cases. C. -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 800 756 6803 (phone) +44 (0) 7759 633626 (mobile) colin.campbell at ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com From chrisc at catalyst.net.nz Wed Sep 17 18:07:55 2014 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Thu, 18 Sep 2014 04:07:55 +1200 Subject: [Koha-devel] Koha and DBIC In-Reply-To: <20140917134934.GA10248@zazou.cscnet.co.uk> References: <1410388901.20051.7.camel@zarathud.wgtn.cat-it.co.nz> <1410398389.20051.24.camel@zarathud.wgtn.cat-it.co.nz> <809BE39CD64BFD4EB9036172EBCCFA31423D34C8@S-MAIL-1B.rijksmuseum.intra> <809BE39CD64BFD4EB9036172EBCCFA31423D7E05@S-MAIL-1B.rijksmuseum.intra> <20140917134934.GA10248@zazou.cscnet.co.uk> Message-ID: <3901e549-a890-4824-ba8c-6277e7078f42@email.android.com> On 18 September 2014 1:49:34 am NZST, Colin Campbell wrote: >On Wed, Sep 17, 2014 at 08:50:37AM -0400, Mark Tompsett wrote: >> Greetings, >> >> > Just to add to the confusion ;) >> > When I wrote "some Koha::Object" here, >> > I was not literally suggesting Koha::Object, >> > I was thinking of something like Koha::Biblio or Koha::Patron etc. >> That?s what I understood. So physically, we may have the tables we >currently have accessed via DBIC, but the Koha::Biblio object would >blend DBIC objects related to Biblios and Items. Right? This would mean >that Koha::Biblio would provide whatever methods regardless of the >backend structure. > >Trouble is it sidesteps fixing the schema. The interplay between biblio >and biblioitems will remain a problem for maintenance in future. There >is already special code added to link the classes because their >relationship is not maintained by the database. Special cases tend to >grow over time and spawn more special cases. > It's not an either/or proposition, having Koha::Biblio doesn't mean you can't fix the schema too. It just means all the business logic for dealing with it is in that module/object. Instead of strewn about in scripts all over the place. Chris >C. > >-- >Colin Campbell >Chief Software Engineer, >PTFS Europe Limited >Content Management and Library Solutions >+44 (0) 800 756 6803 (phone) >+44 (0) 7759 633626 (mobile) >colin.campbell at ptfs-europe.com >skype: colin_campbell2 > >http://www.ptfs-europe.com >_______________________________________________ >Koha-devel mailing list >Koha-devel at 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/ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From kyle.m.hall at gmail.com Wed Sep 17 19:11:33 2014 From: kyle.m.hall at gmail.com (Kyle Hall) Date: Wed, 17 Sep 2014 13:11:33 -0400 Subject: [Koha-devel] Koha and DBIC In-Reply-To: <20140917104923.GA7912@zazou.cscnet.co.uk> References: <1410388901.20051.7.camel@zarathud.wgtn.cat-it.co.nz> <1410398389.20051.24.camel@zarathud.wgtn.cat-it.co.nz> <809BE39CD64BFD4EB9036172EBCCFA31423D34C8@S-MAIL-1B.rijksmuseum.intra> <20140917075041.GC5376@rorohiko.wgtn.cat-it.co.nz> <20140917104923.GA7912@zazou.cscnet.co.uk> Message-ID: I agree. I'd rather use DBIC directly and extend what we already have. It's just an idea if the conclusion is we can't do that. Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) On Wed, Sep 17, 2014 at 6:49 AM, Colin Campbell < colin.campbell at ptfs-europe.com> wrote: > A Koha::Object sounds like extremely poor design. What kind of object is > a Koha::Object, what are its properties, when we say a Koha::Biblio isa > Koha::Object what does that mean? In practice what meaningful properties > it has it inherits from Koha::Schema::Result::Biblio which is liable to > be a better representation than the vaguer Onject. > > In practice I've recently written some scripts which in first version > used some abstractions built around dbic ResultSets, As I added to them > I stripped out out the abstractions and used the dbic result sets as I > found this generated cleaner, more straightforward code. > > Colin > > -- > Colin Campbell > Chief Software Engineer, > PTFS Europe Limited > Content Management and Library Solutions > +44 (0) 800 756 6803 (phone) > +44 (0) 7759 633626 (mobile) > colin.campbell at ptfs-europe.com > skype: colin_campbell2 > > http://www.ptfs-europe.com > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From francois.charbonnier at inlibro.com Wed Sep 17 20:00:56 2014 From: francois.charbonnier at inlibro.com (Francois Charbonnier) Date: Wed, 17 Sep 2014 14:00:56 -0400 Subject: [Koha-devel] Dom indexing operational with a fresh install? In-Reply-To: References: <54184F7D.209@inlibro.com> Message-ID: <5419CC58.1080106@inlibro.com> Thanks! You're right. I was checking the wrong file. The set up is ok. But I still have the same problem. I tried to update biblio-koha-indexdefs.xml following the instructions on this wiki page : http://wiki.koha-community.org/wiki/MRenvoize/zebra I can't make the language index based on the 008 value work. Has someone already tried to fix this? Any advices when updating these dom files? Thanks! Fran?ois Fran?ois Charbonnier, Bibl. prof. / Chef de produits T?l. : (888) 604-2627 francois.charbonnier at inLibro.com inLibro | pour esprit libre | www.inLibro.com Le 2014-09-16 18:29, Tomas Cohen Arazi a ?crit : > > On Tue, Sep 16, 2014 at 11:55 AM, Francois Charbonnier > > wrote: > > > > Hello, > > > > Yesterday, I bumped into an indexing bug. The 008 language code is > not indexed. I can't find the records using this value. I checked on > bugzilla and found this old bug : > http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7586. This > bug changed "ln:n" by "ln:w" in record.abs . > > > > It works with grs-1 indexing. On Katrin advice, I checked if the > installation is using dom or grs-1 indexing. > > > > I'm on 3.14.07. So it should use dom. koha-conf.xml says "dom" but > zebra-biblios.cfg seems to say "grs"... > > Your koha-conf.xml file should be pointing to zebra-biblios-dom.cfg in > the id="biblioserver" section. > > Best regards > To+ > > -- > Tom?s Cohen Arazi > Prosecretar?a de Inform?tica > Universidad Nacional de C?rdoba > ? +54 351 5353750 ext 13168 > GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F > -------------- next part -------------- An HTML attachment was scrubbed... URL: From z.tajoli at cineca.it Wed Sep 17 20:40:02 2014 From: z.tajoli at cineca.it (Zeno Tajoli) Date: Wed, 17 Sep 2014 20:40:02 +0200 (CEST) Subject: [Koha-devel] Dom indexing operational with a fresh install? In-Reply-To: <5419CC58.1080106@inlibro.com> Message-ID: <519674160.4641896.1410979202582.JavaMail.root@cineca.it> Hi Francois, I probably have the same problem. If, as me, you use DOM indexing, you need to fix only marc21/biblios/biblio-koha-indexdefs.xml Probaly the only change to do are the changes written in this comment of Paul Poulain: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7586#c6 After recreate the xsl file with: -- cd ../zebradb/xsl/ -- xsltproc koha-indexdefs-to-zebra.xsl ../marc21/biblios/biblio-koha-indexdefs.xml > ../marc21/biblios/biblio-zebra-indexdefs.xsl -- do a complete reindex of zebra biblio records. I open a bug about this problem, number 12948. Bye ----- Messaggio originale ----- Da: "Francois Charbonnier" A: "Tomas Cohen Arazi" Cc: "dev >> koha-devel" Inviato: Mercoled?, 17 settembre 2014 20:00:56 Oggetto: Re: [Koha-devel] Dom indexing operational with a fresh install? Thanks! You're right. I was checking the wrong file. The set up is ok. But I still have the same problem. I tried to update biblio-koha-indexdefs.xml following the instructions on this wiki page : http://wiki.koha-community.org/wiki/MRenvoize/zebra I can't make the language index based on the 008 value work. Has someone already tried to fix this? Any advices when updating these dom files? Thanks! Fran?ois Fran?ois Charbonnier, Bibl. prof. / Chef de produits T?l. : (888) 604-2627 francois.charbonnier at inLibro.com in Libro | pour esprit libre | www.inLibro.com Le 2014-09-16 18:29, Tomas Cohen Arazi a ?crit : On Tue, Sep 16, 2014 at 11:55 AM, Francois Charbonnier < francois.charbonnier at inlibro.com > wrote: > > Hello, > > Yesterday, I bumped into an indexing bug. The 008 language code is not indexed. I can't find the records using this value. I checked on bugzilla and found this old bug : http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7586 . This bug changed "ln:n" by "ln:w" in record.abs . > > It works with grs-1 indexing. On Katrin advice, I checked if the installation is using dom or grs-1 indexing. > > I'm on 3.14.07. So it should use dom. koha-conf.xml says "dom" but zebra-biblios.cfg seems to say "grs"... Your koha-conf.xml file should be pointing to zebra-biblios-dom.cfg in the id="biblioserver" section. Best regards To+ -- Tom?s Cohen Arazi Prosecretar?a de Inform?tica Universidad Nacional de C?rdoba ? +54 351 5353750 ext 13168 GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F _______________________________________________ Koha-devel mailing list Koha-devel at 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/ From tomascohen at gmail.com Wed Sep 17 21:09:54 2014 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Wed, 17 Sep 2014 16:09:54 -0300 Subject: [Koha-devel] Rebase after passing QA? In-Reply-To: <2C614FEEE2356A428DC65441E30302E0010048A7A5@nero> References: <2C614FEEE2356A428DC65441E30302E0010048A7A5@nero> Message-ID: Tell me the bug number. On Wed, Sep 17, 2014 at 2:32 AM, Holger Meissner < Holger.Meissner at hs-gesundheit.de> wrote: > Dear Koha devs, > > a few weeks ago one of my patches passed QA. By now it doesn't auto-merge > with master anymore. I suspect the conflicts can be resolved without too > much trouble. Should I rebase, keeping the Passed QA status? Or should I > rebase and set back to Signed Off? Or leave it to the RM to rebase? > > Thanks > Holger > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -- Tom?s Cohen Arazi Prosecretar?a de Inform?tica Universidad Nacional de C?rdoba ? +54 351 5353750 ext 13168 GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From kohanews at gmail.com Thu Sep 18 02:25:28 2014 From: kohanews at gmail.com (Koha News) Date: Wed, 17 Sep 2014 17:25:28 -0700 Subject: [Koha-devel] Call for news: September Newsletter Message-ID: <541A2678.6060102@gmail.com> Fellow Koha users ~ We're collecting news for the September newsletter. Send anything noteworthy to: k o h a news AT gmail dot com News criteria: --------------------------- * News items can be of any length. * Anything and everything Koha. * Submit by the 26th. If you are working on an interesting project or development related to Koha, please let us know and we'll include it in the development section. -- Chad Roseburg Joanne Dillon Editors, Koha Newsletter From kohanews at gmail.com Thu Sep 18 02:26:28 2014 From: kohanews at gmail.com (Koha News) Date: Wed, 17 Sep 2014 17:26:28 -0700 Subject: [Koha-devel] Call for development news - September Newsletter Message-ID: <541A26B4.80205@gmail.com> Koha Development community ~ If you have any bugs or projects you'd like us to highlight or promote in the September newsletter, please let us know. Maybe it'll attract some additional eyes, testers and sign-offs. k o h a news AT gmail dot com Thank you! -- Chad Roseburg Joanne Dillon Editors, Koha Newsletter From robin at catalyst.net.nz Thu Sep 18 03:51:17 2014 From: robin at catalyst.net.nz (Robin Sheat) Date: Thu, 18 Sep 2014 13:51:17 +1200 Subject: [Koha-devel] Conventions for CLI scripts Message-ID: <1411005077.20051.59.camel@zarathud.wgtn.cat-it.co.nz> There's been talk of making a few conventions for the parameters to command-line scripts. The initial discussion was dealing with "test mode" where it runs through all the actions but doesn't actually do anything, i.e. you know if it'll complete successfully. 1. There are two directions for this: I. By default the action will be performed, unless you add an argument (--dry-run for example.) II. By default the action will not be performed, unless you add an argument (--commit for example.) 2. What do we want to call the options, whichever way is picked? I. Keeping in mind that some things (-c for example) can conflict with other conventions. 3. Are there any other conventions we should deal with at the same time? While I have your attention, we should be more careful about how the dry run stuff is actually done. I've found one script that gives you a different count if you're in dry run mode (e.g. it'll say "0 actions done") which is strictly correct, but means you don't know if it's 0 because something's wrong, or because it's in dry run mode. Unless there's a good reason, it's best to do everything in a commit, so something like: $dbi->begin_work; ...do stuff... print "$count actions done.\n"; if ($dry_run) { $dbi->rollback; print "Changes NOT committed.\n"; } else { $dbi->commit; } This also has the side effect that if your program crashes in any mode, you're not left with an inconsistent result. But mostly it means that /everything/ will happen in exactly the same way no matter what, except the results just won't be saved. -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part URL: From kumarjammala at gmail.com Thu Sep 18 09:19:37 2014 From: kumarjammala at gmail.com (Vijaya Kumar) Date: Thu, 18 Sep 2014 12:49:37 +0530 Subject: [Koha-devel] Koha-devel Digest, Vol 106, Issue 20 In-Reply-To: References: Message-ID: good morning koha users I am having our library bibliographic details of our library collection above 2 lakhs records in iso 2709 format please explain indetails how to convert in iso2709 from in to koha software. thanking you, your sincerely dr.j.Vijaya Kumar On Wed, Sep 17, 2014 at 4:02 AM, < koha-devel-request at lists.koha-community.org> wrote: > Send Koha-devel mailing list submissions to > koha-devel at 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 at lists.koha-community.org > > You can reach the person managing the list at > koha-devel-owner at 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: problem to perform a simple query (Adnier Rosello) > (Adnier Rosell? Carrazana) > 2. Dom indexing operational with a fresh install? > (Francois Charbonnier) > 3. Re: Dom indexing operational with a fresh install? > (Tomas Cohen Arazi) > 4. Re: Koha and DBIC (Kyle Hall) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 16 Sep 2014 16:15:13 -0400 (CDT) > From: Adnier Rosell? Carrazana > To: koha-devel at lists.koha-community.org > Subject: Re: [Koha-devel] problem to perform a simple query (Adnier > Rosello) > Message-ID: > <1412455981.134123159.1410898513042.JavaMail.zimbra at uci.cu> > Content-Type: text/plain; charset=utf-8 > > Robin: > apology not specify in my previous mail that my koha version is 3.0.6, > which has a preference variable to not use the zebra (NoZebra), so the > search of bibliographic records are handled directly by MySQL, grateful by > the response, I hope to clarify the problem, Greetings > > Ad > ----- Mensaje original ----- > Send Koha-devel mailing list submissions to > koha-devel at 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 at lists.koha-community.org > > You can reach the person managing the list at > koha-devel-owner at 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: Koha and DBIC (Marcel de Rooy) > 2. Re: problem to perform a simple query (Robin Sheat) > 3. VIAF and Koha 3.16.x (Partha Mukhopadhyay) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 15 Sep 2014 19:11:35 +0000 > From: Marcel de Rooy > To: Koha Devel > Subject: Re: [Koha-devel] Koha and DBIC > Message-ID: > > <809BE39CD64BFD4EB9036172EBCCFA31423D34C8 at S-MAIL-1B.rijksmuseum.intra> > Content-Type: text/plain; charset="iso-8859-1" > > > I am troubled by the idea that we should wrap all our dbic classes in > yet more classes. Every example I've seen of this has more code by a factor > of almost 10. I don't know if Koha is so complex that it requires a > repository pattern. > I think that it would require rewriting Koha. This changeover might just > be too complex for us. > > > How much more difficult will this be for developers, and how much more > overhead will it require if we wrap our objects in more objects? We'd have > to fetch the Row objects, wrap them in KohaRow objects, wrap those in a > KohaRowSet, and return them. Certainly, but far more complicated. > I would say: Leave all storage related actions in Koha::Schema. KohaRow > does not make sense to me. > Furthermore, define the objects that actually have 'real' business logic > and put that in some Koha::Object. > > Marcel > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.koha-community.org/pipermail/koha-devel/attachments/20140915/425d46d2/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Tue, 16 Sep 2014 11:26:54 +1200 > From: Robin Sheat > To: koha-devel at lists.koha-community.org > Subject: Re: [Koha-devel] problem to perform a simple query > Message-ID: <1410823613.20051.38.camel at zarathud.wgtn.cat-it.co.nz> > Content-Type: text/plain; charset="utf-8" > > Adnier Rosell? Carrazana schreef op ma 15-09-2014 om 08:54 [-0400]: > > I need to know if the search system koha have any character limitation > > to perform a simple query (without using zebra) > > What do you mean "without using zebra"? There shouldn't be an option to > not use zebra any more. > > -- > Robin Sheat > Catalyst IT Ltd. > ? +64 4 803 2204 > GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 473 bytes > Desc: This is a digitally signed message part > URL: < > http://lists.koha-community.org/pipermail/koha-devel/attachments/20140916/92e8546d/attachment-0001.pgp > > > > ------------------------------ > > Message: 3 > Date: Tue, 16 Sep 2014 08:15:55 +0000 (UTC) > From: Partha Mukhopadhyay > To: koha-devel at lists.koha-community.org > Subject: [Koha-devel] VIAF and Koha 3.16.x > Message-ID: <1466111020.197668.1410855355242.JavaMail.tomcat at be02> > Content-Type: text/plain; charset="us-ascii" > > An HTML attachment was scrubbed... > URL: < > http://lists.koha-community.org/pipermail/koha-devel/attachments/20140916/c053264e/attachment-0001.html > > > > ------------------------------ > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > > End of Koha-devel Digest, Vol 106, Issue 19 > ******************************************* > Concurso "Mi selfie por los 5". Detalles en > http://justiciaparaloscinco.wordpress.com > > > ------------------------------ > > Message: 2 > Date: Tue, 16 Sep 2014 10:55:57 -0400 > From: Francois Charbonnier > To: "dev >> koha-devel" > Subject: [Koha-devel] Dom indexing operational with a fresh install? > Message-ID: <54184F7D.209 at inlibro.com> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Hello, > > Yesterday, I bumped into an indexing bug. The 008 language code is not > indexed. I can't find the records using this value. I checked on > bugzilla and found this old bug : > http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7586. This bug > changed "ln:n" by "ln:w" in record.abs . > > It works with grs-1 indexing. On Katrin advice, I checked if the > installation is using dom or grs-1 indexing. > > I'm on 3.14.07. So it should use dom. koha-conf.xml says "dom" but > zebra-biblios.cfg seems to say "grs"... > > So, I checked "zebra-biblios.cfg" on master and the default values are : > > * iso2709.recordType:grs.marcxml.record > * marcxml.recordType:grs.sgml > * recordType:grs.xml > > Shouldn't we have a reference to dom for these parameters? > > I also checked biblio-zebra-indexdefs.xsl and biblio-koha-indexdefs.xml > and the language index is "ln:n". > I tried to change it by "ln:w", restarted zebra server, reindexed but it > didn't work. > > I followed the wiki instruction > (http://wiki.koha-community.org/wiki/Switching_to_dom_indexing) to > change the "zebra-biblios.cfg" values as well but didn't work either. > > Any ideas? > > Thanks! > -- > Fran?ois Charbonnier, > Bibl. prof. / Chef de produits > > T?l. : (888) 604-2627 > francois.charbonnier at inLibro.com > > inLibro | pour esprit libre | www.inLibro.com > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.koha-community.org/pipermail/koha-devel/attachments/20140916/e431fe2b/attachment-0001.html > > > > ------------------------------ > > Message: 3 > Date: Tue, 16 Sep 2014 19:29:13 -0300 > From: Tomas Cohen Arazi > To: Francois Charbonnier > Cc: "dev >> koha-devel" > Subject: Re: [Koha-devel] Dom indexing operational with a fresh > install? > Message-ID: > XoEQ at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Tue, Sep 16, 2014 at 11:55 AM, Francois Charbonnier < > francois.charbonnier at inlibro.com> wrote: > > > > Hello, > > > > Yesterday, I bumped into an indexing bug. The 008 language code is not > indexed. I can't find the records using this value. I checked on bugzilla > and found this old bug : > http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7586. This bug > changed "ln:n" by "ln:w" in record.abs . > > > > It works with grs-1 indexing. On Katrin advice, I checked if the > installation is using dom or grs-1 indexing. > > > > I'm on 3.14.07. So it should use dom. koha-conf.xml says "dom" but > zebra-biblios.cfg seems to say "grs"... > > Your koha-conf.xml file should be pointing to zebra-biblios-dom.cfg in > the id="biblioserver" section. > > Best regards > To+ > > -- > Tom?s Cohen Arazi > Prosecretar?a de Inform?tica > Universidad Nacional de C?rdoba > ? +54 351 5353750 ext 13168 > GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.koha-community.org/pipermail/koha-devel/attachments/20140916/a2922d99/attachment-0001.html > > > > ------------------------------ > > Message: 4 > Date: Tue, 16 Sep 2014 07:16:18 -0400 > From: Kyle Hall > To: Marcel de Rooy > Cc: Koha Devel > Subject: Re: [Koha-devel] Koha and DBIC > Message-ID: > < > CACpVHfwyGN7ZwOASMTMgFuRagBCotNYvyuK-jY9e7e+-oEsxug at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Yes. I'm imagining something along the lines of Koha::Object, and > Koha::Object::Set which would have all the boilerplate we need for general > use ( get, set, find, search, etc ). Then all our table-tied objects would > inherit from Koha::Object and a set of those objects would inherit from > Koha::Object::Set. Both of those classes can be DBIC-aware internally. > > Internally Koha::Object would have a DBIC Result as a property, which can > be used independently from the database ( which would be good for unit > testing ). Each Koha::Object::Set would normally keep only a ResultSet > internally and work on that until asked to return a Koha::Object, at which > point it would wrap each Result in a Koha::Object and store them > internally, or return an array of them depending on what type of return > value the method was called with. > > I would be willing to write up Koha::Object and Koha::Object::Set if this > is what Robin, Tomas et. al. are looking for. > > In this way we have DBIC totally encapsulated so the code using > Koha::Object and Koha::Object::Set's is totally DBIC unaware but internally > is DBIC aware. > > In addition, if we have these two classes to inherit from, it will reduce > the amount of code we must write, and make it much easier for new > developers. One we have Object and Object::Set written, we don't have to > rewrite our CRUD boilerplate for each and every new class we add. > > What do you think? > > Kyle > > http://www.kylehall.info > ByWater Solutions ( http://bywatersolutions.com ) > Meadville Public Library ( http://www.meadvillelibrary.org ) > Crawford County Federated Library System ( http://www.ccfls.org ) > Mill Run Technology Solutions ( http://millruntech.com ) > > On Mon, Sep 15, 2014 at 3:11 PM, Marcel de Rooy > wrote: > > > > I am troubled by the idea that we should wrap all our dbic classes in > > yet more classes. Every example I've seen of this has more code by a > factor > > of almost 10. I don't know if Koha is so complex that it requires a > > repository pattern. > > I think that it would require rewriting Koha. This changeover might > > just be too complex for us. > > > > > How much more difficult will this be for developers, and how much more > > overhead will it require if we wrap our objects in more objects? We'd > have > > to fetch the Row objects, wrap them in KohaRow objects, wrap those in a > > KohaRowSet, and return them. Certainly, but far more complicated. > > I would say: Leave all storage related actions in Koha::Schema. KohaRow > > does not make sense to me. > > Furthermore, define the objects that actually have 'real' business logic > > and put that in some Koha::Object. > > > > Marcel > > > > _______________________________________________ > > Koha-devel mailing list > > Koha-devel at 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/ > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.koha-community.org/pipermail/koha-devel/attachments/20140916/27e01607/attachment.html > > > > ------------------------------ > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > > End of Koha-devel Digest, Vol 106, Issue 20 > ******************************************* > -- Dr.J.Vijaya Kumar Engineering College Library Andhra University Visakhapatnam- 530 003 Andhra Pradesh India. E-Mail Address: kumarjammala at gmail.com kumarjammala at rediffmail.com jammalamadakavijayakumar at yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From kumarjammala at gmail.com Thu Sep 18 09:24:24 2014 From: kumarjammala at gmail.com (Vijaya Kumar) Date: Thu, 18 Sep 2014 12:54:24 +0530 Subject: [Koha-devel] Koha-devel Digest, Vol 106, Issue 23 In-Reply-To: References: Message-ID: good morning koha users I am having our library bibliographic details above 2 lakhs records in iso 2709 format. please explain in details how to convert records iso2709 format in to koha software. thanking you, your sincerely dr.j.Vijaya Kumar Click here to Reply or Forward 1.7 GB (11%) of 15 GB used Manage ?2014 Google - Terms & Privacy Powered by Last account activity: 35 minutes ago Details Azure StorSimple Solution On Wed, Sep 17, 2014 at 9:37 PM, < koha-devel-request at lists.koha-community.org> wrote: > Send Koha-devel mailing list submissions to > koha-devel at 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 at lists.koha-community.org > > You can reach the person managing the list at > koha-devel-owner at 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: Koha and DBIC (Kyle Hall) > 2. Re: Koha and DBIC (Colin Campbell) > 3. Re: Koha and DBIC (Marcel de Rooy) > 4. Re: Koha and DBIC (Mark Tompsett) > 5. Re: Koha and DBIC (Colin Campbell) > 6. Re: Koha and DBIC (Chris Cormack) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 17 Sep 2014 06:40:09 -0400 > From: Kyle Hall > To: Jonathan Druart , Kyle Hall > , Koha Devel > > Subject: Re: [Koha-devel] Koha and DBIC > Message-ID: > < > CACpVHfyZnF9jpWKW5hGcmXtG4eZFf+YpCzkJGiqEwhm11XkoEA at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Chris, I'm a bit lost here. The idea behind Koha::Object is that we have a > common base class from which to derive Koha::Biblio, Koha::Serial and so > forth. That is, this class would be used as the base for classes that have > a simple 1 to 1 table mapping to encapsulate DBIC while maintaining a > consistent set of methods across our many classes. ObjectSet would give us > set iterators, set operations, and be a better place to have methods that > return a set ( e.g. Koha::Issue::Set::GetOverdues would return a collection > of overdue checkouts ). > > I'm not sure why you disagree with this idea. Could you expand a bit? > > Kyle > > > > -1 for DBIx::Class calls in the .pl > > -1 for Koha::Object and Koha::Object::Set > > +1 for proper objects like Koha::Biblio, Koha::Account, Koha::Serial etc > > > > Chris > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.koha-community.org/pipermail/koha-devel/attachments/20140917/3b5fc3d8/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Wed, 17 Sep 2014 11:49:23 +0100 > From: Colin Campbell > To: koha-devel at lists.koha-community.org > Subject: Re: [Koha-devel] Koha and DBIC > Message-ID: <20140917104923.GA7912 at zazou.cscnet.co.uk> > Content-Type: text/plain; charset=us-ascii > > A Koha::Object sounds like extremely poor design. What kind of object is > a Koha::Object, what are its properties, when we say a Koha::Biblio isa > Koha::Object what does that mean? In practice what meaningful properties > it has it inherits from Koha::Schema::Result::Biblio which is liable to > be a better representation than the vaguer Onject. > > In practice I've recently written some scripts which in first version > used some abstractions built around dbic ResultSets, As I added to them > I stripped out out the abstractions and used the dbic result sets as I > found this generated cleaner, more straightforward code. > > Colin > > -- > Colin Campbell > Chief Software Engineer, > PTFS Europe Limited > Content Management and Library Solutions > +44 (0) 800 756 6803 (phone) > +44 (0) 7759 633626 (mobile) > colin.campbell at ptfs-europe.com > skype: colin_campbell2 > > http://www.ptfs-europe.com > > > ------------------------------ > > Message: 3 > Date: Wed, 17 Sep 2014 12:40:51 +0000 > From: Marcel de Rooy > To: Koha Devel > Subject: Re: [Koha-devel] Koha and DBIC > Message-ID: > > <809BE39CD64BFD4EB9036172EBCCFA31423D7E05 at S-MAIL-1B.rijksmuseum.intra> > Content-Type: text/plain; charset="iso-8859-1" > > > I would say: Leave all storage related actions in Koha::Schema. KohaRow > does not make sense to me. > > Furthermore, define the objects that actually have 'real' business logic > and put that in some Koha::Object. > > Just to add to the confusion ;) When I wrote "some Koha::Object" here, I > was not literally suggesting Koha::Object, I was thinking of something like > Koha::Biblio or Koha::Patron etc. > I would not suggest to add such an object for every table in Koha. We > should clearly define which objects(!) we really need, having sufficient > business logic etc. to justify an interface to DBIx. > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.koha-community.org/pipermail/koha-devel/attachments/20140917/036e8ce9/attachment-0001.html > > > -------------- next part -------------- > An embedded and charset-unspecified text was scrubbed... > Name: ATT00001.txt > URL: < > http://lists.koha-community.org/pipermail/koha-devel/attachments/20140917/036e8ce9/attachment-0001.txt > > > > ------------------------------ > > Message: 4 > Date: Wed, 17 Sep 2014 08:50:37 -0400 > From: "Mark Tompsett" > To: "Marcel de Rooy" > Cc: koha-devel at lists.koha-community.org > Subject: Re: [Koha-devel] Koha and DBIC > Message-ID: > Content-Type: text/plain; charset="utf-8" > > Greetings, > > > Just to add to the confusion ;) > > When I wrote "some Koha::Object" here, > > I was not literally suggesting Koha::Object, > > I was thinking of something like Koha::Biblio or Koha::Patron etc. > That?s what I understood. So physically, we may have the tables we > currently have accessed via DBIC, but the Koha::Biblio object would blend > DBIC objects related to Biblios and Items. Right? This would mean that > Koha::Biblio would provide whatever methods regardless of the backend > structure. > GPML, > Mark Tompsett > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.koha-community.org/pipermail/koha-devel/attachments/20140917/34f28f56/attachment-0001.html > > > > ------------------------------ > > Message: 5 > Date: Wed, 17 Sep 2014 14:49:34 +0100 > From: Colin Campbell > To: koha-devel at lists.koha-community.org > Subject: Re: [Koha-devel] Koha and DBIC > Message-ID: <20140917134934.GA10248 at zazou.cscnet.co.uk> > Content-Type: text/plain; charset=utf-8 > > On Wed, Sep 17, 2014 at 08:50:37AM -0400, Mark Tompsett wrote: > > Greetings, > > > > > Just to add to the confusion ;) > > > When I wrote "some Koha::Object" here, > > > I was not literally suggesting Koha::Object, > > > I was thinking of something like Koha::Biblio or Koha::Patron etc. > > That?s what I understood. So physically, we may have the tables we > currently have accessed via DBIC, but the Koha::Biblio object would blend > DBIC objects related to Biblios and Items. Right? This would mean that > Koha::Biblio would provide whatever methods regardless of the backend > structure. > > Trouble is it sidesteps fixing the schema. The interplay between biblio > and biblioitems will remain a problem for maintenance in future. There > is already special code added to link the classes because their > relationship is not maintained by the database. Special cases tend to > grow over time and spawn more special cases. > > C. > > -- > Colin Campbell > Chief Software Engineer, > PTFS Europe Limited > Content Management and Library Solutions > +44 (0) 800 756 6803 (phone) > +44 (0) 7759 633626 (mobile) > colin.campbell at ptfs-europe.com > skype: colin_campbell2 > > http://www.ptfs-europe.com > > > ------------------------------ > > Message: 6 > Date: Thu, 18 Sep 2014 04:07:55 +1200 > From: Chris Cormack > To: Colin Campbell , > koha-devel at lists.koha-community.org > Subject: Re: [Koha-devel] Koha and DBIC > Message-ID: <3901e549-a890-4824-ba8c-6277e7078f42 at email.android.com> > Content-Type: text/plain; charset=UTF-8 > > > > On 18 September 2014 1:49:34 am NZST, Colin Campbell < > colin.campbell at ptfs-europe.com> wrote: > >On Wed, Sep 17, 2014 at 08:50:37AM -0400, Mark Tompsett wrote: > >> Greetings, > >> > >> > Just to add to the confusion ;) > >> > When I wrote "some Koha::Object" here, > >> > I was not literally suggesting Koha::Object, > >> > I was thinking of something like Koha::Biblio or Koha::Patron etc. > >> That?s what I understood. So physically, we may have the tables we > >currently have accessed via DBIC, but the Koha::Biblio object would > >blend DBIC objects related to Biblios and Items. Right? This would mean > >that Koha::Biblio would provide whatever methods regardless of the > >backend structure. > > > >Trouble is it sidesteps fixing the schema. The interplay between biblio > >and biblioitems will remain a problem for maintenance in future. There > >is already special code added to link the classes because their > >relationship is not maintained by the database. Special cases tend to > >grow over time and spawn more special cases. > > > > It's not an either/or proposition, having Koha::Biblio doesn't mean you > can't fix the schema too. It just means all the business logic for dealing > with it is in that module/object. Instead of strewn about in scripts all > over the place. > > Chris > > > > > >C. > > > >-- > >Colin Campbell > >Chief Software Engineer, > >PTFS Europe Limited > >Content Management and Library Solutions > >+44 (0) 800 756 6803 (phone) > >+44 (0) 7759 633626 (mobile) > >colin.campbell at ptfs-europe.com > >skype: colin_campbell2 > > > >http://www.ptfs-europe.com > >_______________________________________________ > >Koha-devel mailing list > >Koha-devel at 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/ > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > > > ------------------------------ > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > > End of Koha-devel Digest, Vol 106, Issue 23 > ******************************************* > -- Dr.J.Vijaya Kumar Engineering College Library Andhra University Visakhapatnam- 530 003 Andhra Pradesh India. E-Mail Address: kumarjammala at gmail.com kumarjammala at rediffmail.com jammalamadakavijayakumar at yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mtompset at hotmail.com Thu Sep 18 15:29:42 2014 From: mtompset at hotmail.com (Mark Tompsett) Date: Thu, 18 Sep 2014 09:29:42 -0400 Subject: [Koha-devel] Conventions for CLI scripts In-Reply-To: <1411005077.20051.59.camel@zarathud.wgtn.cat-it.co.nz> References: <1411005077.20051.59.camel@zarathud.wgtn.cat-it.co.nz> Message-ID: Greetings, > 1. There are two directions for this: > I. By default the action will be performed, unless you add > an argument (--dry-run for example.) > II. By default the action will not be performed, unless you > add an argument (--commit for example.) If you run a script called DestroyTheDatabase, you would expect the default action to be complete and utter deletion. I think a dry-run flag would make sense for this type of script. The problem is those scripts whose name is not indicative of DB modifications. I suspect you are thinking about checkNonIndexedBiblios.pl which only runs if you include -c, much like point 1 subsection II. The name doesn't suggest default modifications. In this case, you have to add the -z which will then insert the non-indexed Biblios into the zebra queue. This is like the second method. Can we have a mix? Does a mix make any sense? This kind of reminds me of the help for scripts issues I was wondering about. I see a script name, other than reading the code, how do I get a sample use page? Do we force help on users if no parameters are passed? Do we expect a particular letter or phrase? --help -h --usage --examples --something-else? checkNonIndexedBiblios.pl does it both ways. > 2. What do we want to call the options, whichever way is picked? > I. Keeping in mind that some things (-c for example) can > conflict with other conventions. Are there different conventions to choose from? How does Debian (Ubuntu, etc.) do it? > 3. Are there any other conventions we should deal with at the same > time? None of which I am aware. [SNIP] +1 on the turning off auto-commit, so dry runs do the same as actual runs. +1 on the explicit rollback or commit. > $dbi->begin_work; Actually, I guess that is a nicer way of doing this? # Start transaction $dbh->{AutoCommit} = 0; $dbh->{RaiseError} = 1; GPML, Mark Tompsett From oleonard at myacpl.org Thu Sep 18 15:37:33 2014 From: oleonard at myacpl.org (Owen Leonard) Date: Thu, 18 Sep 2014 09:37:33 -0400 Subject: [Koha-devel] Conventions for CLI scripts In-Reply-To: References: <1411005077.20051.59.camel@zarathud.wgtn.cat-it.co.nz> Message-ID: > Do we force help on users if no parameters are passed? As a non-expert in command line things, this is what I would expect. At the very least a brief help, with the suggestion that passing --help would give more. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From tomascohen at gmail.com Thu Sep 18 17:05:23 2014 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Thu, 18 Sep 2014 12:05:23 -0300 Subject: [Koha-devel] Koha Developer IRC meeting 23 September 2014 at 15:00 and 22:00 UTC Message-ID: I'm calling for a dev meeting next week, dedicated to DBIC discussions. We'll have DBIC's Peter Rabbitson on the IRC channel to hear his POV too. He can attend 15:00 UTC only though. I'll be happy to have all positions explicitly stated, and discussed. If we can make a decision, that's bonus points. Please send me your POV so I can put that on the wiki to sumarize what we already discussed. Otherwise, i'll do my best to be impartial. -- Tom?s Cohen Arazi Prosecretar?a de Inform?tica Universidad Nacional de C?rdoba ? +54 351 5353750 ext 13168 GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From robin at catalyst.net.nz Fri Sep 19 01:19:34 2014 From: robin at catalyst.net.nz (Robin Sheat) Date: Fri, 19 Sep 2014 11:19:34 +1200 Subject: [Koha-devel] Conventions for CLI scripts In-Reply-To: References: <1411005077.20051.59.camel@zarathud.wgtn.cat-it.co.nz> Message-ID: <1411082374.20051.78.camel@zarathud.wgtn.cat-it.co.nz> Mark Tompsett schreef op do 18-09-2014 om 09:29 [-0400]: > not indicative of DB modifications. I suspect you are thinking about > checkNonIndexedBiblios.pl which only runs if you include -c, much like point > 1 subsection II. The name doesn't suggest default modifications. Well the solution to that is to fix the name. It's not checking, it's modifying. To be fair, fsck (filesystem check) also modifies :) > In this > case, you have to add the -z which will then insert the non-indexed Biblios > into the zebra queue. This is like the second method. Can we have a mix? > Does a mix make any sense? A mix sounds like the worst of both possible worlds. I don't have strong opinions about it (though ceteris paribus would prefer having "commit" by default), but it's the sort of case where consistency would be good. > This kind of reminds me of the help for scripts issues I was wondering > about. I see a script name, other than reading the code, how do I get a > sample use page? Do we force help on users if no parameters are passed? Do > we expect a particular letter or > phrase? --help -h --usage --examples --something-else? > checkNonIndexedBiblios.pl does it both ways. If a script requires arguments in order to do its function, then it should present with a help synopsis. If it doesn't, then it might go forth and do its thing. This is the UNIX way. If you want help, you use -h or --help. This is the GNU way, which is mostly the POSIX way, which is mostly the UNIX way. I also tend to use --man for providing the full manual, but I'm not sure where I got that idea from. --version is also more or less a GNU requirement, but it's perhaps not so important for us. > > > > 2. What do we want to call the options, whichever way is picked? > > I. Keeping in mind that some things (-c for example) can > > conflict with other conventions. > > Are there different conventions to choose from? How does Debian (Ubuntu, > etc.) do it? I did a bit of pottering around, and while there are many different things, the most common I saw was -c for config file. So it'd probably be best to avoid that. Other things are fair game (except --help and --version I guess.) My suggestion is that we use --dry-run|-d if we have an option to activate that mode, or --run|-r if we require an option to commit changes. Note that no matter what is decided, the "delete_everything_and_burn_it_all_down" script should require a parameter to commit changes. Perhaps '--screw-it-lets-do-it-live'. > > $dbi->begin_work; > > Actually, I guess that is a nicer way of doing this? > > # Start transaction > $dbh->{AutoCommit} = 0; > $dbh->{RaiseError} = 1; It wasn't really a complete example. RaiseError should always be 1 unless you have a reason, I think starting a transaction turns off AutoCommit for the duration of the transaction anyway. -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part URL: From barton at bywatersolutions.com Fri Sep 19 23:51:25 2014 From: barton at bywatersolutions.com (Barton) Date: Fri, 19 Sep 2014 17:51:25 -0400 Subject: [Koha-devel] Introduction: Barton Chittenden, Bywater Solutions Message-ID: <541CA55D.60505@bywatersolutions.com> Hello, Koha-dev! A quick intro, per the mailing list welcome message. My name is Barton Chittenden, I do technical support for Bywater Solutions. I've been working there since November. Most of you probably recognize me as 'barton' on #koha. I wrote my first Perl script in 2000, and started doing ETL work (Extract/Transform/Load, aka data munging) around 2001 or 2002. I've been a Unix Weenie since 1995, and did my first Slackware Linux install in 1999. I've worked as a perl programmer in a Linux environment ever since. I tend to write perl and shell scripts in the course of trouble-shooting for Bywater, and I'm always looking for ways to automate the process of trouble-shooting. Koha is the first open source project that I've worked on. One of my goals over the next year or so is to get more involved with bug signoff, leading into QA. Eventually, I would like to do development. Thanks, --Barton From tomascohen at gmail.com Fri Sep 19 23:56:47 2014 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Fri, 19 Sep 2014 18:56:47 -0300 Subject: [Koha-devel] Introduction: Barton Chittenden, Bywater Solutions In-Reply-To: <541CA55D.60505@bywatersolutions.com> References: <541CA55D.60505@bywatersolutions.com> Message-ID: I'm no sure it applies (we have interacted a lot already) but : WELCOME :-D To+ On Fri, Sep 19, 2014 at 6:51 PM, Barton wrote: > Hello, Koha-dev! > > A quick intro, per the mailing list welcome message. > > My name is Barton Chittenden, I do technical support for Bywater > Solutions. I've been working there since November. Most of you probably > recognize me as 'barton' on #koha. > > I wrote my first Perl script in 2000, and started doing ETL work > (Extract/Transform/Load, aka data munging) around 2001 or 2002. I've been a > Unix Weenie since 1995, and did my first Slackware Linux install in 1999. > I've worked as a perl programmer in a Linux environment ever since. > > I tend to write perl and shell scripts in the course of trouble-shooting > for Bywater, and I'm always looking for ways to automate the process of > trouble-shooting. > > Koha is the first open source project that I've worked on. One of my goals > over the next year or so is to get more involved with bug signoff, leading > into QA. Eventually, I would like to do development. > > Thanks, > > --Barton > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -- Tom?s Cohen Arazi Prosecretar?a de Inform?tica Universidad Nacional de C?rdoba ? +54 351 5353750 ext 13168 GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From kumarjammala at gmail.com Sat Sep 20 08:06:36 2014 From: kumarjammala at gmail.com (Vijaya Kumar) Date: Sat, 20 Sep 2014 11:36:36 +0530 Subject: [Koha-devel] Koha-devel Digest, Vol 106, Issue 27 In-Reply-To: References: Message-ID: GOOD MORNING KOHA USERS, KINDLY ARRANGE TO SEND EASY METHOD RELATAED TO HOW TO INSTALL KOHA SOFTWARE ON LINUX PLATFORM. THANKING YOU YOU, YOURS SINCERELY DR.J.VIJAYA KUMAR On Fri, Sep 19, 2014 at 3:30 PM, < koha-devel-request at lists.koha-community.org> wrote: > Send Koha-devel mailing list submissions to > koha-devel at 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 at lists.koha-community.org > > You can reach the person managing the list at > koha-devel-owner at 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: Conventions for CLI scripts (Mark Tompsett) > 2. Re: Conventions for CLI scripts (Owen Leonard) > 3. Koha Developer IRC meeting 23 September 2014 at 15:00 and > 22:00 UTC (Tomas Cohen Arazi) > 4. Re: Conventions for CLI scripts (Robin Sheat) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 18 Sep 2014 09:29:42 -0400 > From: "Mark Tompsett" > To: "Koha Devel" > Subject: Re: [Koha-devel] Conventions for CLI scripts > Message-ID: > Content-Type: text/plain; format=flowed; charset="utf-8"; > reply-type=original > > Greetings, > > > 1. There are two directions for this: > > I. By default the action will be performed, unless you add > > an argument (--dry-run for example.) > > II. By default the action will not be performed, unless you > > add an argument (--commit for example.) > > If you run a script called DestroyTheDatabase, you would expect the default > action to be complete and utter deletion. I think a dry-run flag would make > sense for this type of script. The problem is those scripts whose name is > not indicative of DB modifications. I suspect you are thinking about > checkNonIndexedBiblios.pl which only runs if you include -c, much like > point > 1 subsection II. The name doesn't suggest default modifications. In this > case, you have to add the -z which will then insert the non-indexed Biblios > into the zebra queue. This is like the second method. Can we have a mix? > Does a mix make any sense? > > This kind of reminds me of the help for scripts issues I was wondering > about. I see a script name, other than reading the code, how do I get a > sample use page? Do we force help on users if no parameters are passed? Do > we expect a particular letter or > phrase? --help -h --usage --examples --something-else? > checkNonIndexedBiblios.pl does it both ways. > > > > 2. What do we want to call the options, whichever way is picked? > > I. Keeping in mind that some things (-c for example) can > > conflict with other conventions. > > Are there different conventions to choose from? How does Debian (Ubuntu, > etc.) do it? > > > > 3. Are there any other conventions we should deal with at the same > > time? > > None of which I am aware. > > [SNIP] > +1 on the turning off auto-commit, so dry runs do the same as actual runs. > +1 on the explicit rollback or commit. > > > > $dbi->begin_work; > > Actually, I guess that is a nicer way of doing this? > > # Start transaction > $dbh->{AutoCommit} = 0; > $dbh->{RaiseError} = 1; > > GPML, > Mark Tompsett > > > > ------------------------------ > > Message: 2 > Date: Thu, 18 Sep 2014 09:37:33 -0400 > From: Owen Leonard > To: Koha Devel > Subject: Re: [Koha-devel] Conventions for CLI scripts > Message-ID: > rS_235Bdf2YSVnd03wO063h9g at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > > Do we force help on users if no parameters are passed? > > As a non-expert in command line things, this is what I would expect. > At the very least a brief help, with the suggestion that passing > --help would give more. > > -- Owen > > -- > Web Developer > Athens County Public Libraries > http://www.myacpl.org > > > ------------------------------ > > Message: 3 > Date: Thu, 18 Sep 2014 12:05:23 -0300 > From: Tomas Cohen Arazi > To: koha-devel > Subject: [Koha-devel] Koha Developer IRC meeting 23 September 2014 at > 15:00 and 22:00 UTC > Message-ID: > X94ca854xgq0enhSj+4iemD1ez1zm3S_99nrU2B8S96A at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > I'm calling for a dev meeting next week, dedicated to DBIC discussions. > > We'll have DBIC's Peter Rabbitson on the IRC channel to hear his POV too. > He can attend 15:00 UTC only though. > > I'll be happy to have all positions explicitly stated, and discussed. If we > can make a decision, that's bonus points. > > Please send me your POV so I can put that on the wiki to sumarize what we > already discussed. Otherwise, i'll do my best to be impartial. > > -- > Tom?s Cohen Arazi > Prosecretar?a de Inform?tica > Universidad Nacional de C?rdoba > ? +54 351 5353750 ext 13168 > GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.koha-community.org/pipermail/koha-devel/attachments/20140918/06a86435/attachment-0001.html > > > > ------------------------------ > > Message: 4 > Date: Fri, 19 Sep 2014 11:19:34 +1200 > From: Robin Sheat > To: koha-devel at lists.koha-community.org > Subject: Re: [Koha-devel] Conventions for CLI scripts > Message-ID: <1411082374.20051.78.camel at zarathud.wgtn.cat-it.co.nz> > Content-Type: text/plain; charset="utf-8" > > Mark Tompsett schreef op do 18-09-2014 om 09:29 [-0400]: > > not indicative of DB modifications. I suspect you are thinking about > > checkNonIndexedBiblios.pl which only runs if you include -c, much like > point > > 1 subsection II. The name doesn't suggest default modifications. > > Well the solution to that is to fix the name. It's not checking, it's > modifying. To be fair, fsck (filesystem check) also modifies :) > > > In this > > case, you have to add the -z which will then insert the non-indexed > Biblios > > into the zebra queue. This is like the second method. Can we have a mix? > > Does a mix make any sense? > > A mix sounds like the worst of both possible worlds. I don't have strong > opinions about it (though ceteris paribus would prefer having "commit" > by default), but it's the sort of case where consistency would be good. > > > This kind of reminds me of the help for scripts issues I was wondering > > about. I see a script name, other than reading the code, how do I get a > > sample use page? Do we force help on users if no parameters are passed? > Do > > we expect a particular letter or > > phrase? --help -h --usage --examples --something-else? > > checkNonIndexedBiblios.pl does it both ways. > > If a script requires arguments in order to do its function, then it > should present with a help synopsis. If it doesn't, then it might go > forth and do its thing. This is the UNIX way. > > If you want help, you use -h or --help. This is the GNU way, which is > mostly the POSIX way, which is mostly the UNIX way. I also tend to use > --man for providing the full manual, but I'm not sure where I got that > idea from. > > --version is also more or less a GNU requirement, but it's perhaps not > so important for us. > > > > > > > > 2. What do we want to call the options, whichever way is picked? > > > I. Keeping in mind that some things (-c for example) can > > > conflict with other conventions. > > > > Are there different conventions to choose from? How does Debian (Ubuntu, > > etc.) do it? > > I did a bit of pottering around, and while there are many different > things, the most common I saw was -c for config file. So it'd probably > be best to avoid that. Other things are fair game (except --help and > --version I guess.) > > My suggestion is that we use --dry-run|-d if we have an option to > activate that mode, or --run|-r if we require an option to commit > changes. > > Note that no matter what is decided, the > "delete_everything_and_burn_it_all_down" script should require a > parameter to commit changes. Perhaps '--screw-it-lets-do-it-live'. > > > > $dbi->begin_work; > > > > Actually, I guess that is a nicer way of doing this? > > > > # Start transaction > > $dbh->{AutoCommit} = 0; > > $dbh->{RaiseError} = 1; > > It wasn't really a complete example. RaiseError should always be 1 > unless you have a reason, I think starting a transaction turns off > AutoCommit for the duration of the transaction anyway. > > -- > Robin Sheat > Catalyst IT Ltd. > ? +64 4 803 2204 > GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 473 bytes > Desc: This is a digitally signed message part > URL: < > http://lists.koha-community.org/pipermail/koha-devel/attachments/20140919/764862af/attachment-0001.pgp > > > > ------------------------------ > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > > End of Koha-devel Digest, Vol 106, Issue 27 > ******************************************* > -- Dr.J.Vijaya Kumar Engineering College Library Andhra University Visakhapatnam- 530 003 Andhra Pradesh India. E-Mail Address: kumarjammala at gmail.com kumarjammala at rediffmail.com jammalamadakavijayakumar at yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From indradg at gmail.com Sat Sep 20 08:34:28 2014 From: indradg at gmail.com (indradg) Date: Sat, 20 Sep 2014 12:04:28 +0530 Subject: [Koha-devel] Koha-devel Digest, Vol 106, Issue 27 Message-ID: The easiest option usually involves engaging a Koha consultant or consulting company. There is a list on the website - Paid Support. Sent from Samsung Mobile -------- Original message -------- From: Vijaya Kumar Date:20/09/2014 11:36 (GMT+05:30) To: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] Koha-devel Digest, Vol 106, Issue 27 GOOD MORNING KOHA USERS, ?? KINDLY ARRANGE TO SEND EASY METHOD? RELATAED TO HOW TO INSTALL KOHA SOFTWARE ON LINUX? PLATFORM. THANKING YOU YOU, YOURS SINCERELY DR.J.VIJAYA KUMAR On Fri, Sep 19, 2014 at 3:30 PM, wrote: Send Koha-devel mailing list submissions to ? ? ? ? koha-devel at 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 at lists.koha-community.org You can reach the person managing the list at ? ? ? ? koha-devel-owner at 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: Conventions for CLI scripts (Mark Tompsett) ? ?2. Re: Conventions for CLI scripts (Owen Leonard) ? ?3. Koha Developer IRC meeting 23 September 2014 at 15:00? ? ?and ? ? ? 22:00 UTC (Tomas Cohen Arazi) ? ?4. Re: Conventions for CLI scripts (Robin Sheat) ---------------------------------------------------------------------- Message: 1 Date: Thu, 18 Sep 2014 09:29:42 -0400 From: "Mark Tompsett" To: "Koha Devel" Subject: Re: [Koha-devel] Conventions for CLI scripts Message-ID: Content-Type: text/plain; format=flowed; charset="utf-8"; ? ? ? ? reply-type=original Greetings, >? ? ?1. There are two directions for this: >? ? ? ? ? ? ?I. By default the action will be performed, unless you add >? ? ? ? ? ? ? ? an argument (--dry-run for example.) >? ? ? ? ? ? II. By default the action will not be performed, unless you >? ? ? ? ? ? ? ? add an argument (--commit for example.) If you run a script called DestroyTheDatabase, you would expect the default action to be complete and utter deletion. I think a dry-run flag would make sense for this type of script. The problem is those scripts whose name is not indicative of DB modifications. I suspect you are thinking about checkNonIndexedBiblios.pl which only runs if you include -c, much like point 1 subsection II. The name doesn't suggest default modifications. In this case, you have to add the -z which will then insert the non-indexed Biblios into the zebra queue. This is like the second method. Can we have a mix? Does a mix make any sense? This kind of reminds me of the help for scripts issues I was wondering about. I see a script name, other than reading the code, how do I get a sample use page? Do we force help on users if no parameters are passed? Do we expect a particular letter or phrase? --help -h --usage --examples --something-else? checkNonIndexedBiblios.pl does it both ways. >? ? ?2. What do we want to call the options, whichever way is picked? >? ? ? ? ? ? ?I. Keeping in mind that some things (-c for example) can >? ? ? ? ? ? ? ? conflict with other conventions. Are there different conventions to choose from? How does Debian (Ubuntu, etc.) do it? >? ? ?3. Are there any other conventions we should deal with at the same >? ? ? ? time? None of which I am aware. [SNIP] +1 on the turning off? auto-commit, so dry runs do the same as actual runs. +1 on the explicit rollback or commit. >? ? ? ? $dbi->begin_work; Actually, I guess that is a nicer way of doing this? # Start transaction $dbh->{AutoCommit} = 0; $dbh->{RaiseError} = 1; GPML, Mark Tompsett ------------------------------ Message: 2 Date: Thu, 18 Sep 2014 09:37:33 -0400 From: Owen Leonard To: Koha Devel Subject: Re: [Koha-devel] Conventions for CLI scripts Message-ID: ? ? ? ? Content-Type: text/plain; charset=UTF-8 > Do we force help on users if no parameters are passed? As a non-expert in command line things, this is what I would expect. At the very least a brief help, with the suggestion that passing --help would give more. ?-- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org ------------------------------ Message: 3 Date: Thu, 18 Sep 2014 12:05:23 -0300 From: Tomas Cohen Arazi To: koha-devel Subject: [Koha-devel] Koha Developer IRC meeting 23 September 2014 at ? ? ? ? 15:00? ?and 22:00 UTC Message-ID: ? ? ? ? Content-Type: text/plain; charset="utf-8" I'm calling for a dev meeting next week, dedicated to DBIC discussions. We'll have DBIC's Peter Rabbitson on the IRC channel to hear his POV too. He can attend 15:00 UTC only though. I'll be happy to have all positions explicitly stated, and discussed. If we can make a decision, that's bonus points. Please send me your POV so I can put that on the wiki to sumarize what we already discussed. Otherwise, i'll do my best to be impartial. -- Tom?s Cohen Arazi Prosecretar?a de Inform?tica Universidad Nacional de C?rdoba ? +54 351 5353750 ext 13168 GPG: B76C 6E7C 2D80 551A C765? E225 0A27 2EA1 B2F3 C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 4 Date: Fri, 19 Sep 2014 11:19:34 +1200 From: Robin Sheat To: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] Conventions for CLI scripts Message-ID: <1411082374.20051.78.camel at zarathud.wgtn.cat-it.co.nz> Content-Type: text/plain; charset="utf-8" Mark Tompsett schreef op do 18-09-2014 om 09:29 [-0400]: > not indicative of DB modifications. I suspect you are thinking about > checkNonIndexedBiblios.pl which only runs if you include -c, much like point > 1 subsection II. The name doesn't suggest default modifications. Well the solution to that is to fix the name. It's not checking, it's modifying. To be fair, fsck (filesystem check) also modifies :) > In this > case, you have to add the -z which will then insert the non-indexed Biblios > into the zebra queue. This is like the second method. Can we have a mix? > Does a mix make any sense? A mix sounds like the worst of both possible worlds. I don't have strong opinions about it (though ceteris paribus would prefer having "commit" by default), but it's the sort of case where consistency would be good. > This kind of reminds me of the help for scripts issues I was wondering > about. I see a script name, other than reading the code, how do I get a > sample use page? Do we force help on users if no parameters are passed? Do > we expect a particular letter or > phrase? --help -h --usage --examples --something-else? > checkNonIndexedBiblios.pl does it both ways. If a script requires arguments in order to do its function, then it should present with a help synopsis. If it doesn't, then it might go forth and do its thing. This is the UNIX way. If you want help, you use -h or --help. This is the GNU way, which is mostly the POSIX way, which is mostly the UNIX way. I also tend to use --man for providing the full manual, but I'm not sure where I got that idea from. --version is also more or less a GNU requirement, but it's perhaps not so important for us. > > > >? ? ?2. What do we want to call the options, whichever way is picked? > >? ? ? ? ? ? ?I. Keeping in mind that some things (-c for example) can > >? ? ? ? ? ? ? ? conflict with other conventions. > > Are there different conventions to choose from? How does Debian (Ubuntu, > etc.) do it? I did a bit of pottering around, and while there are many different things, the most common I saw was -c for config file. So it'd probably be best to avoid that. Other things are fair game (except --help and --version I guess.) My suggestion is that we use --dry-run|-d if we have an option to activate that mode, or --run|-r if we require an option to commit changes. Note that no matter what is decided, the "delete_everything_and_burn_it_all_down" script should require a parameter to commit changes. Perhaps '--screw-it-lets-do-it-live'. > >? ? ? ? $dbi->begin_work; > > Actually, I guess that is a nicer way of doing this? > > # Start transaction > $dbh->{AutoCommit} = 0; > $dbh->{RaiseError} = 1; It wasn't really a complete example. RaiseError should always be 1 unless you have a reason, I think starting a transaction turns off AutoCommit for the duration of the transaction anyway. -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38? 8505 77F5 B724 F871 3BDF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part URL: ------------------------------ _______________________________________________ Koha-devel mailing list Koha-devel at 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/ End of Koha-devel Digest, Vol 106, Issue 27 ******************************************* -- Dr.J.Vijaya Kumar Engineering College Library Andhra University Visakhapatnam- 530 003 Andhra Pradesh India. E-Mail Address: kumarjammala at gmail.com kumarjammala at rediffmail.com jammalamadakavijayakumar at yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From veron at veron.ch Sat Sep 20 22:02:54 2014 From: veron at veron.ch (=?UTF-8?B?TWFyYyBWw6lyb24=?=) Date: Sat, 20 Sep 2014 22:02:54 +0200 Subject: [Koha-devel] Sign-off request for Bug 12162 - Add class="branchcode" to body tag to make OPAC CSS-styleable per branch Message-ID: <541DDD6E.1090507@veron.ch> Hi Koha community, A couple of weeks ago I submitted a patch that makes the OPAC CSS-styleable per branch: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12162 It would be great if somebody would have time to for a sign-off. Thanks and regards Marc From jonathan.druart at biblibre.com Mon Sep 22 14:01:20 2014 From: jonathan.druart at biblibre.com (Jonathan Druart) Date: Mon, 22 Sep 2014 14:01:20 +0200 Subject: [Koha-devel] Koha Developer IRC meeting 23 September 2014 at 15:00 and 22:00 UTC In-Reply-To: References: Message-ID: Hello all, I have just created a wiki page [1]. I hope everyone will add their pros and cons to get a list as complete as possible for the meeting. Cheers, Jonathan http://wiki.koha-community.org/wiki/DBIC_discussion_overview 2014-09-18 17:05 GMT+02:00 Tomas Cohen Arazi : > I'm calling for a dev meeting next week, dedicated to DBIC discussions. > > We'll have DBIC's Peter Rabbitson on the IRC channel to hear his POV too. He > can attend 15:00 UTC only though. > > I'll be happy to have all positions explicitly stated, and discussed. If we > can make a decision, that's bonus points. > > Please send me your POV so I can put that on the wiki to sumarize what we > already discussed. Otherwise, i'll do my best to be impartial. > > -- > Tom?s Cohen Arazi > Prosecretar?a de Inform?tica > Universidad Nacional de C?rdoba > ? +54 351 5353750 ext 13168 > GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ From oleonard at myacpl.org Wed Sep 24 14:03:44 2014 From: oleonard at myacpl.org (Owen Leonard) Date: Wed, 24 Sep 2014 08:03:44 -0400 Subject: [Koha-devel] Reminder: Koha general IRC meeting 24 September at 14:00 UTC Message-ID: The next Koha general IRC meeting will be taking place in just a couple of hours! http://www.timeanddate.com/worldclock/fixedtime.html?msg=Koha+IRC+General+Meeting&iso=20140924T14 The agenda is here: http://wiki.koha-community.org/wiki/General_IRC_meeting_24_September_2014 -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From dptkvs at gmail.com Thu Sep 25 06:13:26 2014 From: dptkvs at gmail.com (DP Tripathi) Date: Thu, 25 Sep 2014 09:43:26 +0530 Subject: [Koha-devel] Regarding SMS Integration with Koha Message-ID: Dear Friends, I am trying to integrate Clickatell Perl Script in order to send SMS through Koha in India but failed to do so. If anyone please help me how to set this? Thanks -- ********************* D. P. Tripathi Assistant Librarian Biju Patnaik Central Library NIT Rourkela Odisha - 769008 ********************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.druart at biblibre.com Thu Sep 25 09:25:57 2014 From: jonathan.druart at biblibre.com (Jonathan Druart) Date: Thu, 25 Sep 2014 09:25:57 +0200 Subject: [Koha-devel] Regarding SMS Integration with Koha In-Reply-To: References: Message-ID: Hello D.P., What is the "Clickatell perl script"? You need to write a driver based on SMS::Send::Driver. Regards, Jonathan 2014-09-25 6:13 GMT+02:00 DP Tripathi : > Dear Friends, > > I am trying to integrate Clickatell Perl Script in order to send SMS through > Koha in India but failed to do so. > > If anyone please help me how to set this? > > Thanks > > -- > ********************* > D. P. Tripathi > Assistant Librarian > Biju Patnaik Central Library > NIT Rourkela > Odisha - 769008 > ********************** > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ From jonathan.druart at biblibre.com Thu Sep 25 10:02:48 2014 From: jonathan.druart at biblibre.com (Jonathan Druart) Date: Thu, 25 Sep 2014 10:02:48 +0200 Subject: [Koha-devel] Regarding SMS Integration with Koha In-Reply-To: References: Message-ID: The driver module is on the cpan: http://search.cpan.org/~nobull/SMS-Send-Clickatell-0.02/lib/SMS/Send/Clickatell.pm You just have to fill the pref SMSSendUsername SMSSendDriver with Clickatell. The driver needs 3 values: api_id, user and password. Only the password can be filled by one of the Koha sms pref (SMSSendPassword). I developed a patch to permit to pass more than the "login" and "password" parameter to the driver. It has not been submitted on bugzilla. You can find it on the BibLibre repository: https://git.biblibre.com/biblibre/kohac/commit/49644ebf043c92ed0665388d1d292f57d4f1f3d6 The short version is: it won't work out of the box. Regards, Jonathan PS: Please answer to the list. 2014-09-25 9:29 GMT+02:00 Dp Tripathi : > Dear Sir, > > Clickatell is company which provides the script to send the SMS. The same > name is recommended in Koha manual also to start sms, integrate anyone of > the following such as > > Clickatell > > Wadja > > ipipi > > Sir, if you have driver, please help me and send me the script and also > guide me to integrate. I will be highly thankful to you. > > Thanks, > > On Thu, Sep 25, 2014 at 3:25 AM, Jonathan Druart > wrote: >> >> Hello D.P., >> >> What is the "Clickatell perl script"? >> You need to write a driver based on SMS::Send::Driver. >> >> Regards, >> Jonathan >> >> 2014-09-25 6:13 GMT+02:00 DP Tripathi : >> > Dear Friends, >> > >> > I am trying to integrate Clickatell Perl Script in order to send SMS >> > through >> > Koha in India but failed to do so. >> > >> > If anyone please help me how to set this? >> > >> > Thanks >> > >> > -- >> > ********************* >> > D. P. Tripathi >> > Assistant Librarian >> > Biju Patnaik Central Library >> > NIT Rourkela >> > Odisha - 769008 >> > ********************** >> > >> > _______________________________________________ >> > Koha-devel mailing list >> > Koha-devel at 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/ > > > > > -- > ************************************************************ > Dhanwantari Prakash Tripathi > Assistant Librarian > Biju Patnaik Central Library > National Institute of Technology > Rourkela, Odisha - INDIA > 769008 > e-mail: tripathidp at nitrkl.ac.in, dptnitrkl at gmail.com > mobile: +91-8895296796 > URL: www.librarianguide.co.in > URL: www.koha.librarianguide.co.in > URL: www.forum.librarianguide.co.in > ************************************************************ From koha at akafred.com Tue Sep 30 09:41:23 2014 From: koha at akafred.com (akafred) Date: Tue, 30 Sep 2014 09:41:23 +0200 Subject: [Koha-devel] Presentation to mailing list: akafred Message-ID: Hi! Just a short intro as per the welcome mail: I am contracted by the Oslo Public Library (Deichmanske bibliotek) in Norway to help out in their efforts to build systems for their new library that will open in Oslo in a few years. Koha has been chosen as a cornerstone in this effort. I have been working as a consultant for 15+ years, developing business critical systems for clients in and around Oslo. I LOVE programming, but I also have a passion for quality and a certain disdain for repetitive tasks, and error prone, manual, routines - so I am very into Test-Driven Development (London-style), automation (e g using provisioning tools like Ansible, SaltStack, Puppet, Chef) and prefer properly tested deployment units (like a jar, war, Docker image or, if all else fails, a virtual machine image). Generally, I think learning is what all development efforts should optimize their efforts for, and that transparency, collaboration and rapid feedback are key ingredients in achieving that. The better we are at learning the better we will be at creating awesome stuff that works for our end users. We are in an early phase in our efforts but if you are curious a lot of what we do will be publicly available on our github profile: https://github.com/digibib These days we are looking into how to deploy Koha in Docker. My real name is impossible for non-Norwegians to parse, remember and pronounce so on the interwebs I mostly go by a nickname I chose in a moment of general unclarity and confusion: "Fred" ... so I am a.k.a Fred .... akafred. I try to stop by #koha as akafred, but not always 'there' even if it looks like it - koha at akafred.com works though. See ya :-) Regards, - Kjetil a.k.a. "Fred" -------------- next part -------------- An HTML attachment was scrubbed... URL: