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

Jenkins
by Mark Tompsett 06 Oct '16

06 Oct '16

Greetings, http://jenkins.koha-community.org/ They are all offline. With Kyle Hall’s patching up the the Kitchen Sink plug-in with JD’s patch, I was hoping to see a current run with happiness. Any idea what is going on? GPML, Mark Tompsett

1 0

Sandboxes Signoff
by Fridolin SOMERS 06 Oct '16

06 Oct '16

Hie, I'm setting up our new sandboxes. Applying patches is ok but not signoff. In bugzilla the status turns to "signed off", the current patch is set obsolete but the new patch is not attached. Applying patch now calls misc/devel/update_dbix_class_files.pl, with may change some files in sources. I may be the cause of the problem. Maybe add git stash / git stash pop to sandbox_signoff.cron ? Best regards, -- Fridolin SOMERS Biblibre - Pôles support et système fridolin.somers(a)biblibre.com

1 0

How do we find consensus on interface changes?
by Owen Leonard 06 Oct '16

06 Oct '16

Do we need a procedure for getting consensus on Koha interface changes? I'm thinking about this issue in part because of a couple of interface changes I've been working on. One for Bug 16421: Move hold edit actions into dropdown menu https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16421 (screenshot: https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=51111) ...and another for Bug 11375: Patron permission names are untranslatable https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11375 (screenshot: https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=51847) When proposing a change like that should there be a more inclusive process than getting one sign-off and one QA approval? If so, how do we decide what kind of changes require wider approval? How do we solicit opinions from a wider audience? Or is the process working well as-is? -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org

9 15

Koha packages: a directory for spooled data
by David Cook 06 Oct '16

06 Oct '16

Hi all, What would be a good directory to use for spooled data when using Koha packages? Ideally, I'd like to use /var/spool/koha/<koha-instance>/. However, only the root user is about to write to that directory. This isn't really a problem for source installs or dev installs, since we control our own permissions, but it'll be a problem for package installs. I suppose a person could use /tmp, but that's not really appropriate, since /tmp isn't necessarily persistent. You might have a /tmp with tmpfs, have a server reboot, and then lose your spooled data. The answer to me is to allow the koha-instance user to write to /var/spool/koha/<koha-instance> as well. However, I want to hear what other people think, and hear about any alternative directory ideas. Cheers, David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595

1 0

Koha 3.22/16.05 & Apache, Plack for a high load/large library
by Paul Poulain 04 Oct '16

04 Oct '16

Hello koha-devel, Is there someone using Apache, Plack, on a high load server (ie: for a large library) ? Which configuration are you using (OS version, how is Koha installed -package or not-, any tuning in the config files ?) Do you face any problem ? We (BibLibre) face many cases where we get failures ("internal server error". Seems there's something like Apache not being able to wait long enough for Plack to answer). -- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries

5 4

Improving the API for record imports
by David Cook 03 Oct '16

03 Oct '16

Hi all, I want to improve the API(s) for importing (bibliographic) records. But I'm not 100% sure how to go about what criteria to use to gauge "improvement". Here are some ideas: * I think the REST API offers up one obvious addition and that's DELETE. It would be great to delete records using the API. I've found this mostly thanks to OAI-PMH where you get a notice when a record has been deleted upstream and needs to be deleted from Koha too. o The difficulty in deleting bibliographic records is items. If there are items, it blocks the delete. You could auto-delete items, but you can't if there are holds or if it's currently issued. At best, you could return a failed delete via the API, I think. * I keep thinking that "import profiles" could be a good way to go too. This might include a MARC Modification Template, it might be a XSLT, it might be a Koha::Filter. It would let you turns your incoming metadata from format A to format B. o This would also allow you to POST a minimum amount of data to the API. You'd have your metadata record and your import profile code. * The downside of this is the POST wouldn't detail the options for the import, and those imports would be more obfuscated. Changes to a profile could also impact subsequent imports unintentionally. o I'm not sure how batches would work with filtering. You might have 50/100 records filter correctly and import, but that leaves 50 which aren't imported. Do you undo the whole import, or do you fix your filter, and then re-import the first 50 alongside the first time import of the last 50? * The original metadata would be stored regardless of metadata format (e.g. marcxml, mods, rdf, dc, etc.) for historical purposes or to allow re-filtering in the event that a filter fails to correctly transform a record to valid MARCXML (or whatever internal metadata format Koha uses). * The import source and the type of import would be stored (ie http://oai-server.com and "oai-pmh", lx2.loc.gov and "z3950", <insert relevant source> and "oclc connexion", etc.). o I think this would be helpful for managing/processing a certain type of import, perhaps also in terms of matching records. o At the moment, with my work on #10662, I have a separate table "import_oai" which obviously is for records imported via oai-pmh only. I don't actually track the origin due to how I currently source the imports, but I could do it in the future. * Storing some sort of identifier would be good o OAI-PMH records have unique identifiers for the records o Z39.50. that's tougher since it's not a specific metadata format like the OAI-PMH format. So I don't know about this one. Anyway, these are just some ideas I've been having. They're not fully formed by any stretch of the imagination. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595

4 4

Koha Community Newsletter: September 2016
by kohanews 30 Sep '16

30 Sep '16

Fellow Koha users: The Koha Community Newsletter for September 2016 is here: https://koha-community.org/koha-community-newsletter-september-2016/ Many thanks to the folks who submitted articles and news to this month's newsletter. Please feel free to email me with any corrections or suggestions. Thanks! -- Chad Roseburg Editor, Koha Community Newsletter

1 0

Bug 5670: Housebound Module
by Alex Sassmannshausen 29 Sep '16

29 Sep '16

Hello, Whilst putting finishing touches on Bug 5670 Housebound Readers Module, a discussion was started on the best way to handle database architecture for a part of the feature. Jonathan, who has been heavily involved in reviewing the patch series so far, quite rightly suggested we get some additional opinions. You can read the discussion on the bug (it's quite old, the last few comments are probably most relevant), but as a summary (primarily of my perspective): The housebound module relies on assigning one or two roles to patrons registered in Koha. Patrons can be 'deliverers' (delivering items to housebound patrons), 'choosers' (selecting items which can then be delivered by deliverers), or both. The current implementation uses extended patron attributes, but I would agree that this implementation is probably sub-optimal for the use case of the Housebound module. We are now debating whether it is better to add 2 new columns to the borrowers table (increasing the number of columns from 69 to 71), for the two new roles, or whether we should create a new table, called 'housebound_role' to go with 'housebound_profile' and 'housebound_visit', which consists of - borrower_id (foreign key to borrowers.borrowernumber) - deliverer (boolean) - chooser (boolean) My personal feeling is that the latter approach is better for the following reasons: - Housebound module is an optional feature switched on in sysprefs. - For the sites that enable it, I would expect that only a small percentage of all registered patrons become volunteers As a result, the housebound_role table will be empty for sites that have the feature disabled, and small for sites that have it enabled. Going with the former approach will implicitly create values for every patron in the installation, even if the feature is switched off. For future development, making changes to the housebound_role table would be less intrusive than making changes to the borrowers table. Finally, from a data integrity perspective, I cannot see either approach being better or worse at this point: the foreign key constraint will ensure data integrity, and the table is normalized in either case (though I'm certainly not an expert in this area). WDYT? Best wishes, Alex

2 1

Re: [Koha-devel] Elasticsearch not searching.
by Tomas Cohen Arazi 29 Sep '16

29 Sep '16

Its ok if you want to try ElasticSearch even though it is experimental. But aren't you migrating a production service? El jue., 29 sept. 2016 a las 9:57, Rodrigo Santellan (<rsantellan(a)gmail.com>) escribió: > Tomas, > > I have attached all the vagrant files. > > For installing it I use: > - vagrant up > - vagrant ssh > - sudo sh /vagrant/provisioning/enviromentsSettings.sh > - exit > - vagrant ssh > - sh /vagrant/provisioning/fullProvisioning.sh > - sh /vagrant/provisioning/makeKoha.sh #Choose the dev installation > - sudo sh /vagrant/provisioning/apacheEnviroment.sh > - sudo systemctl restart apache2 > - sudo systemctl restart mysql > - cd /vagrant/provisioning/kohaMigrationData/ > - gunzip < koha.sql.gz | mysql -u root -p # Old instance of koha 2.2.3 > - cat /vagrant/provisioning/koha3-schema.sql | mysql -u root -p > - nohup ./importData.sh > - mv nohup nohup.importdata > - nohup ./runscripts.sh > > I'm running all the scripts that I need by hand. > > I'm trying to understand the new (for me) Koha so I can maximize the time > I have to work on it, thats why I don't run the packages installer. I also > have the problem that I know I have to modify it :( > > Thanks for the help! > > > On Thu, Sep 29, 2016 at 9:38 AM, Tomas Cohen Arazi <tomascohen(a)gmail.com> > wrote: > >> Dood, just: >> - launch a clean VBox with Debian 8 or Ubuntu 16.04 >> - install mysql-server (in Ubuntu 16.04 install mariadb-server) >> - Add the repo, install koha-common >> - $ sudo koha-create --create-db test_library >> >> And that's all of it. It is working for everyone else, so please try to >> write some more detailed install/setup steps so we understand what's going >> on. >> >> PS: if this was a dev box, you need https://github.com/mkfifo/koha-gitify >> >> El jue., 29 sept. 2016 a las 9:31, Rodrigo Santellan (< >> rsantellan(a)gmail.com>) escribió: >> >>> David, >>> >>> I tried running the Kohadevbox but I have fail because I'm behind a >>> proxy and the provisioning fails and I can't start up the machine. >>> >>> So my next step was to create a empty Vagrant with the box: >>> bento/ubuntu-16.04 and run post install scripts. >>> >>> The default version installed on ubuntu 16.04 is: >>> >>> idzebra-2.0: >>> Installed: 2.0.59-1 >>> Candidate: 2.0.59-1 >>> >>> I have successfully run the searches with Elasticsearch. Now I have to >>> see if I'm missing something or not because using Elasticsearch instead of >>> Zebra! >>> >>> Thanks for your help! >>> >>> Regards >>> >>> >>> On Wed, Sep 28, 2016 at 10:04 PM, David Cook <dcook(a)prosentient.com.au> >>> wrote: >>> >>>> Also, if you're having issues with Zebra, you can try posting to this >>>> list, >>>> as there are a number of us who can probably help you. >>>> >>>> I see that you posted before about trying to see how many biblios are >>>> indexed in Zebra, and that you had a problem using _ALLRECORDS. Did you >>>> have >>>> any other problems? Were you able to successfully perform other Zebra >>>> searches? >>>> >>>> I admit that the error "[114] Unsupported Use attribute -- v2 addinfo >>>> '_ALLRECORDS'" is rather difficult to figure out. Usually, if you see >>>> that >>>> 114 code, it means that a particular index hasn't been created yet >>>> within >>>> the Zebra database*. However, since you're using the special index >>>> _ALLRECORDS, it should be created. >>>> >>>> It looks like you're using Zebra 2.0.44. That should support >>>> _ALLRECORDS. >>>> I'm on Zebra 2.0.60, and this is the output I see: >>>> >>>> Z> find @attr 1=_ALLRECORDS @attr 2=103 "" >>>> Sent searchRequest. >>>> Received SearchResponse. >>>> Search was a success. >>>> Number of hits: 956, setno 2 >>>> SearchResult-1: term= cnt=956 >>>> records returned: 0 >>>> Elapsed: 0.010064 >>>> >>>> I just tried It on a Debian server running Zebra 2.0.44 and I see this >>>> output: >>>> Z> find @attr 1=_ALLRECORDS @attr 2=103 "" >>>> Sent searchRequest. >>>> Received SearchResponse. >>>> Search was a success. >>>> Number of hits: 14882, setno 1 >>>> SearchResult-1: term= cnt=14882 >>>> records returned: 0 >>>> Elapsed: 0.028209 >>>> >>>> Even if I delete all the records in my database, I still see: >>>> >>>> Z> find @attr 1=_ALLRECORDS @attr 2=103 "" >>>> Sent searchRequest. >>>> Received SearchResponse. >>>> Search was a success. >>>> Number of hits: 0, setno 1 >>>> SearchResult-1: term= cnt=0 >>>> records returned: 0 >>>> Elapsed: 0.007409 >>>> >>>> Your Zebra database "biblios" appears to be created otherwise you'd see: >>>> >>>> Z> find @attr 1=_ALLRECORDS @attr 2=103 "" >>>> Sent searchRequest. >>>> Received SearchResponse. >>>> Search was a bloomin' failure. >>>> Number of hits: 0, setno 1 >>>> Result Set Status: none >>>> records returned: 0 >>>> Diagnostic message(s) from database: >>>> [109] Database unavailable -- v2 addinfo 'biblios' >>>> Elapsed: 0.001682 >>>> >>>> Hmm... my best guess is that somehow your Zebra install has been >>>> corrupted >>>> maybe. I'm not really sure. This is a very bizarre error. >>>> >>>> How did you install Koha and Zebra? I notice the home directory for a >>>> vagrant user... is this a Kohadevbox? >>>> >>>> >>>> >>>> >>>> >>>> >>>> * >>>> In this particular database, I've only ever had 1 record, and it >>>> contained >>>> very little data. It contained a title, so the following search works: >>>> Z> find @attr 1=4 "test" >>>> Sent searchRequest. >>>> Received SearchResponse. >>>> Search was a success. >>>> Number of hits: 0, setno 5 >>>> SearchResult-1: term=test cnt=0 >>>> records returned: 0 >>>> Elapsed: 0.002783 >>>> >>>> However, the record never contained an author, so the following search >>>> fails >>>> with that Error 114: >>>> Z> find @attr 1=1 "Bob" >>>> Sent searchRequest. >>>> Received SearchResponse. >>>> Search was a bloomin' failure. >>>> Number of hits: 0, setno 6 >>>> Result Set Status: none >>>> records returned: 0 >>>> Diagnostic message(s) from database: >>>> [114] Unsupported Use attribute -- v2 addinfo '1' >>>> Elapsed: 0.000289 >>>> >>>> David Cook >>>> Systems Librarian >>>> Prosentient Systems >>>> 72/330 Wattle St >>>> Ultimo, NSW 2007 >>>> Australia >>>> >>>> Office: 02 9212 0899 >>>> Direct: 02 8005 0595 >>>> >>>> >>>> > -----Original Message----- >>>> > From: koha-devel-bounces(a)lists.koha-community.org [mailto:koha-devel- >>>> > bounces(a)lists.koha-community.org] On Behalf Of Chris Cormack >>>> > Sent: Thursday, 29 September 2016 6:53 AM >>>> > To: Rodrigo Santellan <rsantellan(a)gmail.com> >>>> > Cc: koha-devel <koha-devel(a)lists.koha-community.org> >>>> > Subject: Re: [Koha-devel] Elasticsearch not searching. >>>> > >>>> > * Rodrigo Santellan (rsantellan(a)gmail.com) wrote: >>>> > > Chris I will install Elastic 1.7 and try again!! It should be on the >>>> > > wiki or the bugzilla issue that tracks the elasticsearch >>>> development. >>>> > > >>>> > > Thank a lot for the quick response! >>>> > >>>> > You could also follow this bug >>>> > >>>> > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17255 >>>> > >>>> > It may be that with the new packages there, it might work already. >>>> > It hasnt been tested yet though >>>> > >>>> > Chris >>>> > >>>> > > >>>> > > On Wed, Sep 28, 2016 at 5:43 PM, Chris Cormack < >>>> chrisc(a)catalyst.net.nz> >>>> > wrote: >>>> > > >>>> > > Hi Rodrigo >>>> > > >>>> > > ElasticSearch in Koha currently only works with Elastic 1.7 >>>> > > We are working on upgrading it to working the latest version but >>>> there >>>> > > were some non backward compatible changes. That is what you are >>>> > bumping >>>> > > into >>>> > > >>>> > > Support in Koha is still experimental, but it once we upgrade it >>>> should be >>>> > > more >>>> > > solid. >>>> > > >>>> > > You could try installing 1.7 and seeing how you go >>>> > > >>>> > > Chris >>>> > > >>>> > > >>>> > > * Rodrigo Santellan (rsantellan(a)gmail.com) wrote: >>>> > > > Hi, >>>> > > > >>>> > > > I have installed Elasticsearch after giving up on Zebra. I >>>> have >>>> follow >>>> > > the the >>>> > > > wiki: https://wiki.koha-community.org/wiki/Elasticsearch# >>>> > > Install_elasticsearch >>>> > > > and installed latest Elasticsearch through the official >>>> repository. >>>> > > > >>>> > > > My installed version is: >>>> > > > curl -XGET 'localhost:9200' >>>> > > > { >>>> > > > "name" : "Her", >>>> > > > "cluster_name" : "elasticsearch", >>>> > > > "cluster_uuid" : "yuU4XtZwT1WtK1SH-3Xofw", >>>> > > > "version" : { >>>> > > > "number" : "2.4.1", >>>> > > > "build_hash" : "c67dc32e24162035d18d6fe1e952c4cbcbe79d16", >>>> > > > "build_timestamp" : "2016-09-27T18:57:55Z", >>>> > > > "build_snapshot" : false, >>>> > > > "lucene_version" : "5.5.2" >>>> > > > }, >>>> > > > "tagline" : "You Know, for Search" >>>> > > > } >>>> > > > >>>> > > > I have run the script perl >>>> misc/search_tools/rebuild_elastic_search.pl -v >>>> > > -d >>>> > > > like the documentation says and I have this error: >>>> > > > Failed to parse mapping [data]: analyzer on field >>>> [Local-number] >>>> must >>>> > be >>>> > > set >>>> > > > when search_analyzer is set >>>> > > > >>>> > > > The log on the elasticsearch.log is >>>> > > > >>>> > > > [2016-09-28 20:27:55,272][DEBUG][action.admin.indices.create] >>>> [Her] >>>> > > > [koha_dev_biblios] failed to create >>>> > > > MapperParsingException[Failed to parse mapping [data]: >>>> analyzer on >>>> > field >>>> > > > [Local-number] must be set when search_analyzer is set]; >>>> nested: >>>> > > > MapperParsingException[analyzer on field [Local-number] must >>>> be >>>> set >>>> > when >>>> > > > search_analyzer is set]; >>>> > > > at org.elasticsearch.index.mapper.MapperService.merge >>>> > > > (MapperService.java:291) >>>> > > > at >>>> > > > >>>> > >>>> org.elasticsearch.cluster.metadata.MetaDataCreateIndexService$1.execute >>>> > > > (MetaDataCreateIndexService.java:317) >>>> > > > at >>>> org.elasticsearch.cluster.ClusterStateUpdateTask.execute >>>> > > > (ClusterStateUpdateTask.java:45) >>>> > > > at >>>> > > > org.elasticsearch.cluster.service.InternalClusterService. >>>> > > runTasksForExecutor >>>> > > > (InternalClusterService.java:468) >>>> > > > at >>>> > > > >>>> > >>>> org.elasticsearch.cluster.service.InternalClusterService$UpdateTask.run >>>> > > > (InternalClusterService.java:772) >>>> > > > at >>>> > > > >>>> > >>>> org.elasticsearch.common.util.concurrent.PrioritizedEsThreadPoolExecutor$ >>>> > > TieBreakingPrioritizedRunnable.runAndClean >>>> > > > (PrioritizedEsThreadPoolExecutor.java:231) >>>> > > > at >>>> > > > >>>> > >>>> org.elasticsearch.common.util.concurrent.PrioritizedEsThreadPoolExecutor$ >>>> > > TieBreakingPrioritizedRunnable.run >>>> > > > (PrioritizedEsThreadPoolExecutor.java:194) >>>> > > > at java.util.concurrent.ThreadPoolExecutor.runWorker >>>> > > > (ThreadPoolExecutor.java:1142) >>>> > > > at java.util.concurrent.ThreadPoolExecutor$Worker.run >>>> > > > (ThreadPoolExecutor.java:617) >>>> > > > at java.lang.Thread.run(Thread.java:745) >>>> > > > Caused by: MapperParsingException[analyzer on field >>>> [Local-number] >>>> > must >>>> > > be set >>>> > > > when search_analyzer is set] >>>> > > > at >>>> > > > org.elasticsearch.index.mapper.core.TypeParsers. >>>> > > parseAnalyzersAndTermVectors >>>> > > > (TypeParsers.java:234) >>>> > > > at >>>> org.elasticsearch.index.mapper.core.TypeParsers.parseTextField >>>> > > > (TypeParsers.java:250) >>>> > > > at >>>> > > > >>>> > org.elasticsearch.index.mapper.core.StringFieldMapper$TypeParser.parse >>>> > > > (StringFieldMapper.java:165) >>>> > > > at >>>> > > > org.elasticsearch.index.mapper.object.ObjectMapper$ >>>> > > TypeParser.parseProperties >>>> > > > (ObjectMapper.java:309) >>>> > > > at >>>> > > > org.elasticsearch.index.mapper.object.ObjectMapper$TypeParser. >>>> > > parseObjectOrDocumentTypeProperties >>>> > > > (ObjectMapper.java:222) >>>> > > > at >>>> > > > >>>> > org.elasticsearch.index.mapper.object.RootObjectMapper$TypeParser.pars >>>> > e >>>> > > > (RootObjectMapper.java:139) >>>> > > > at >>>> org.elasticsearch.index.mapper.DocumentMapperParser.parse >>>> > > > (DocumentMapperParser.java:118) >>>> > > > at >>>> org.elasticsearch.index.mapper.DocumentMapperParser.parse >>>> > > > (DocumentMapperParser.java:99) >>>> > > > at org.elasticsearch.index.mapper.MapperService.parse >>>> > > > (MapperService.java:549) >>>> > > > at org.elasticsearch.index.mapper.MapperService.merge >>>> > > > (MapperService.java:319) >>>> > > > at org.elasticsearch.index.mapper.MapperService.merge >>>> > > > (MapperService.java:289) >>>> > > > ... 9 more >>>> > > > >>>> > > > I'm again at a loss, I believe the problem is on the method: >>>> > > > get_elasticsearch_mappings in Koha::ElasticSearch but I don't >>>> know >>>> > how to >>>> > > > follow it.! >>>> > > > >>>> > > > Regards and thank for any help!! >>>> > > > >>>> > > > Rodrigo >>>> > > >>>> > > > _______________________________________________ >>>> > > > Koha-devel mailing list >>>> > > > Koha-devel(a)lists.koha-community.org >>>> > > > >>>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >>>> > > > website : http://www.koha-community.org/ >>>> > > > git : http://git.koha-community.org/ >>>> > > > bugs : http://bugs.koha-community.org/ >>>> > > >>>> > > >>>> > > -- >>>> > > Chris Cormack >>>> > > Catalyst IT Ltd. >>>> > > +64 4 803 2238 >>>> > > PO Box 11-053, Manners St, Wellington 6142, New Zealand >>>> > > >>>> > > >>>> > >>>> > > _______________________________________________ >>>> > > Koha-devel mailing list >>>> > > Koha-devel(a)lists.koha-community.org >>>> > > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >>>> > > website : http://www.koha-community.org/ git : >>>> > > http://git.koha-community.org/ bugs : >>>> http://bugs.koha-community.org/ >>>> > >>>> > >>>> > -- >>>> > Chris Cormack >>>> > Catalyst IT Ltd. >>>> > +64 4 803 2238 >>>> > PO Box 11-053, Manners St, Wellington 6142, New Zealand >>>> >>>> >>>> >>> _______________________________________________ >>> Koha-devel mailing list >>> Koha-devel(a)lists.koha-community.org >>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >>> website : http://www.koha-community.org/ >>> git : http://git.koha-community.org/ >>> bugs : http://bugs.koha-community.org/ >> >> -- >> Tomás Cohen Arazi >> Theke Solutions (https://theke.io <http://theke.io/>) >> ✆ +54 9351 3513384 >> GPG: B2F3C15F >> > > -- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 GPG: B2F3C15F

1 0

Elasticsearch not searching.
by Rodrigo Santellan 29 Sep '16

29 Sep '16

Hi, I have installed Elasticsearch after giving up on Zebra. I have follow the the wiki: https://wiki.koha-community.org/wiki/Elasticsearch#Install_elasticsearch and installed latest Elasticsearch through the official repository. My installed version is: curl -XGET 'localhost:9200' { "name" : "Her", "cluster_name" : "elasticsearch", "cluster_uuid" : "yuU4XtZwT1WtK1SH-3Xofw", "version" : { "number" : "2.4.1", "build_hash" : "c67dc32e24162035d18d6fe1e952c4cbcbe79d16", "build_timestamp" : "2016-09-27T18:57:55Z", "build_snapshot" : false, "lucene_version" : "5.5.2" }, "tagline" : "You Know, for Search" } I have run the script perl misc/search_tools/rebuild_elastic_search.pl -v -d like the documentation says and I have this error: Failed to parse mapping [data]: analyzer on field [Local-number] must be set when search_analyzer is set The log on the elasticsearch.log is [2016-09-28 20:27:55,272][DEBUG][action.admin.indices.create] [Her] [koha_dev_biblios] failed to create MapperParsingException[Failed to parse mapping [data]: analyzer on field [Local-number] must be set when search_analyzer is set]; nested: MapperParsingException[analyzer on field [Local-number] must be set when search_analyzer is set]; at org.elasticsearch.index.mapper.MapperService.merge(MapperService.java:291) at org.elasticsearch.cluster.metadata.MetaDataCreateIndexService$1.execute(MetaDataCreateIndexService.java:317) at org.elasticsearch.cluster.ClusterStateUpdateTask.execute(ClusterStateUpdateTask.java:45) at org.elasticsearch.cluster.service.InternalClusterService.runTasksForExecutor(InternalClusterService.java:468) at org.elasticsearch.cluster.service.InternalClusterService$UpdateTask.run(InternalClusterService.java:772) at org.elasticsearch.common.util.concurrent.PrioritizedEsThreadPoolExecutor$TieBreakingPrioritizedRunnable.runAndClean(PrioritizedEsThreadPoolExecutor.java:231) at org.elasticsearch.common.util.concurrent.PrioritizedEsThreadPoolExecutor$TieBreakingPrioritizedRunnable.run(PrioritizedEsThreadPoolExecutor.java:194) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: MapperParsingException[analyzer on field [Local-number] must be set when search_analyzer is set] at org.elasticsearch.index.mapper.core.TypeParsers.parseAnalyzersAndTermVectors(TypeParsers.java:234) at org.elasticsearch.index.mapper.core.TypeParsers.parseTextField(TypeParsers.java:250) at org.elasticsearch.index.mapper.core.StringFieldMapper$TypeParser.parse(StringFieldMapper.java:165) at org.elasticsearch.index.mapper.object.ObjectMapper$TypeParser.parseProperties(ObjectMapper.java:309) at org.elasticsearch.index.mapper.object.ObjectMapper$TypeParser.parseObjectOrDocumentTypeProperties(ObjectMapper.java:222) at org.elasticsearch.index.mapper.object.RootObjectMapper$TypeParser.parse(RootObjectMapper.java:139) at org.elasticsearch.index.mapper.DocumentMapperParser.parse(DocumentMapperParser.java:118) at org.elasticsearch.index.mapper.DocumentMapperParser.parse(DocumentMapperParser.java:99) at org.elasticsearch.index.mapper.MapperService.parse(MapperService.java:549) at org.elasticsearch.index.mapper.MapperService.merge(MapperService.java:319) at org.elasticsearch.index.mapper.MapperService.merge(MapperService.java:289) ... 9 more I'm again at a loss, I believe the problem is on the method: get_elasticsearch_mappings in Koha::ElasticSearch but I don't know how to follow it.! Regards and thank for any help!! Rodrigo

4 6