Advanced search Queries in Nozebra mode, via Nozebra table, queriying column named 'indexname', returning __RAW__ and failing in Search.pm
Hello, this is Ignacio, new to the excellent Koha, prepared to put my hands on.. I'm working with koha-3.00.00.005 (debian etch, perl 5.8.8, ran in apache 2 via mod_perl) and after configuring searches in noZebra mode I'm having some problems to patch C4::Search to make it correctly parse and return advanced queries. I'm stuck with advanced search queries in Nozebra mode (via koha mysql's nozebra table), failing in Search.pm: The snippet of code that selects which value of column indexname for the advanced query in question is needed is given by: $left='title' if $left eq 'ti'; $left='author' if $left eq 'au'; $left='publisher' if $left eq 'pb'; $left='subject' if $left eq 'su'; $left='koha-Auth-Number' if $left eq 'an'; $left='keyword' if $left eq 'kw'; .. The problem seems to appear when you find that this column, in my mysql tables koha installation, seems single and only valued __RAW__, so searches result in no rows. Is there anyway to change this behaviour of avoiding this everlasting __RAW__ or is this the expected behavior and there is some other configuration/version problem? Thanks, Ignacio Javier
Ignacio a écrit :
Hello, this is Ignacio, new to the excellent Koha, prepared to put my hands on….
I’m working with koha-3.00.00.005 (debian etch, perl 5.8.8, ran in apache 2 via mod_perl) and after configuring searches in noZebra mode I’m having some problems to patch C4::Search to make it correctly parse and return advanced queries. I’m stuck with advanced search queries in Nozebra mode (via koha mysql’s nozebra table), failing in Search.pm:
The snippet of code that selects which value of column indexname for the advanced query in question is needed is given by:
$left='title' if $left eq 'ti';
$left='author' if $left eq 'au';
$left='publisher' if $left eq 'pb';
$left='subject' if $left eq 'su';
$left='koha-Auth-Number' if $left eq 'an';
$left='keyword' if $left eq 'kw';
…. The problem seems to appear when you find that this column, in my mysql tables koha installation, seems single and only valued __RAW__, so searches result in no rows.
Is there anyway to change this behaviour of avoiding this everlasting __RAW__ or is this the expected behavior and there is some other configuration/version problem?
Thanks,
Ignacio Javier
Hi Ignacio. Welcome on board. In order to work with NoZebra, you have to set up a NoZebraIndexes systemrpeferences value : For instance for a UNIMARC flavour 'title' => '200a,200c,200d,200e,225a,225d,225e,225f,225h,225i,225v,500*,501*,503*,510*,512*,513*,514*,515*,516*,517*,518*,519*,520*,530*,531*,532*,540*,541*,545*,604t,610t,605a', 'author'=>'200f,600a,601a,604a,700a,700b,700c,700d,700a,701b,701c,701d,702a,702b,702c,702d,710a,710b,710c,710d,711a,711b,711c,711d,712a,712b,712c,712d', 'se'=>'225a', 'isbn' => '010a', 'issn' => '011a', 'biblionumber' =>'0909', 'itemtype' => '200b', 'language' => '101a', 'pl' => '210a', 'publisher' => '210c', 'date' => '210d', 'note' => '300a,301a,302a,303a,304a,305a,306az,307a,308a,309a,310a,311a,312a,313a,314a,315a,316a,317a,318a,319a,320a,321a,322a,323a,324a,325a,326a,327a,328a,330a,332a,333a,336a,337a,345a', 'an' => '6009,6019,6069,6109,6079', 'su' => '600a,601a,606a,610a,607a,608a', 'lcn'=>'686a,995k', 'yr'=>'210d', 'mt' => '200b', 'dewey' => '676a', 'host-item' => '995b,995c','keyword' => '200*,600*,700*,400*,210*' Then use the script rebuildnozebra.pl if you already have some biblios. Hope that helps. -- Henri-Damien LAURENT
I made the rebuild but there are still some rows that contain __RAW__ value and same for new catalog entries, they are stablishing a default value for indexname to the value '__RAW__' each time I add a a new entry to the catalog. The basic search makes a 'value' column matching of this table, but advanced search filters make a more granular selection using parameters (title, subject, ISBN, etc...) that are matching against a __RAW__ value that seems being generated (instead title, subject, etc...) in nozebra table each time a new entry is catalogued. The script seems to add some indexname = title, author, etc... entries, but does not fix raw entries added before. It seems to be a problem inherited caused by misconfiguration. Some ideas? -----Mensaje original----- De: koha-devel-bounces+ignacio.gomez=coremain.com@nongnu.org [mailto:koha-devel-bounces+ignacio.gomez=coremain.com@nongnu.org] En nombre de Henri-Damien LAURENT Enviado el: lunes, 19 de noviembre de 2007 16:59 Para: Ignacio CC: koha-devel@nongnu.org Asunto: Re: [Koha-devel] Advanced search Queries in Nozebra mode, via Nozebratable, queriying column named 'indexname',returning __RAW__ and failing in Search.pm Ignacio a écrit :
Hello, this is Ignacio, new to the excellent Koha, prepared to put my hands on .
Im working with koha-3.00.00.005 (debian etch, perl 5.8.8, ran in apache 2 via mod_perl) and after configuring searches in noZebra mode Im having some problems to patch C4::Search to make it correctly parse and return advanced queries. Im stuck with advanced search queries in Nozebra mode (via koha mysqls nozebra table), failing in Search.pm:
The snippet of code that selects which value of column indexname for the advanced query in question is needed is given by:
$left='title' if $left eq 'ti';
$left='author' if $left eq 'au';
$left='publisher' if $left eq 'pb';
$left='subject' if $left eq 'su';
$left='koha-Auth-Number' if $left eq 'an';
$left='keyword' if $left eq 'kw';
. The problem seems to appear when you find that this column, in my mysql tables koha installation, seems single and only valued __RAW__, so searches result in no rows.
Is there anyway to change this behaviour of avoiding this everlasting __RAW__ or is this the expected behavior and there is some other configuration/version problem?
Thanks,
Ignacio Javier
Hi Ignacio. Welcome on board. In order to work with NoZebra, you have to set up a NoZebraIndexes systemrpeferences value : For instance for a UNIMARC flavour 'title' => '200a,200c,200d,200e,225a,225d,225e,225f,225h,225i,225v,500*,501*,503*,510*, 512*,513*,514*,515*,516*,517*,518*,519*,520*,530*,531*,532*,540*,541*,545*,6 04t,610t,605a', 'author'=>'200f,600a,601a,604a,700a,700b,700c,700d,700a,701b,701c,701d,702a, 702b,702c,702d,710a,710b,710c,710d,711a,711b,711c,711d,712a,712b,712c,712d', 'se'=>'225a', 'isbn' => '010a', 'issn' => '011a', 'biblionumber' =>'0909', 'itemtype' => '200b', 'language' => '101a', 'pl' => '210a', 'publisher' => '210c', 'date' => '210d', 'note' => '300a,301a,302a,303a,304a,305a,306az,307a,308a,309a,310a,311a,312a,313a,314a ,315a,316a,317a,318a,319a,320a,321a,322a,323a,324a,325a,326a,327a,328a,330a, 332a,333a,336a,337a,345a', 'an' => '6009,6019,6069,6109,6079', 'su' => '600a,601a,606a,610a,607a,608a', 'lcn'=>'686a,995k', 'yr'=>'210d', 'mt' => '200b', 'dewey' => '676a', 'host-item' => '995b,995c','keyword' => '200*,600*,700*,400*,210*' Then use the script rebuildnozebra.pl if you already have some biblios. Hope that helps. -- Henri-Damien LAURENT _______________________________________________ Koha-devel mailing list Koha-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/koha-devel
On 2007/11/20, at 6:12 AM, Ignacio wrote:
I made the rebuild but there are still some rows that contain __RAW__ value and same for new catalog entries, they are stablishing a default value for indexname to the value '__RAW__' each time I add a a new entry to the catalog.
The basic search makes a 'value' column matching of this table, but advanced search filters make a more granular selection using parameters (title, subject, ISBN, etc...) that are matching against a __RAW__ value that seems being generated (instead title, subject, etc...) in nozebra table each time a new entry is catalogued.
The script seems to add some indexname = title, author, etc... entries, but does not fix raw entries added before.
It seems to be a problem inherited caused by misconfiguration. Some ideas?
Hiya Ignacio, Easy questions first :) What marc flavour are you using, UNIMARC or MARC21. ? I have been working on some MARC21 imports this week, and have found some little tricks, for MARC21 nozebra at least how does your nozebra table look if you run this sql?? heres mine. mysql> select distinct(indexname) from nozebra; +--------------+ | indexname | +--------------+ | author | | bc | | biblionumber | | date | | host-item | | isbn | | note | | subject | | title | | __RAW__ | +--------------+ 10 rows in set (0.03 sec)
First of all, thanks for your reply, Mason, and thanks for the previous Henri reply (my reply o this didn't reach the list), but the fact is reconstruction using UNIMARC didn't fix the whole. To the point, your query results in my machine "result" to return: ---------- 'author' 'isbn' 'note' 'subject' 'title' '__RAW__' ----------- I manually set marcflavour row to UNIMARC in systempreferences table (then I made it from administration panel to ensure the case of some additional action is taken, and rerun build_nozebra.pl script), to obtain the rows listed above, previously it was set to MARC21 and the above query resulted to be a single row: ----------- '__RAW__' ----------- As it seems advanced search fails when I try to search catalog entries inserted by us before, that continue to appear with __RAW__ attribute, which affects new entries. Only some particular entries have indexname column to Other than __RAW__. For example we added an entry some time ago that was titled "El gato con botas", this now results in nozebra table having: SELECT * FROM nozebra b WHERE biblionumbers LIKE '%2,gatoconbot-1;%' +--------------+-----------+-------+---------------------------------------- -------+ | server | indexname | value | biblionumbers | +--------------+-----------+-------+---------------------------------------- -------+ | biblioserver | __RAW__ | bks | 2,gatoconbot-1;9,eljamónde-1;9,eljamóndej-1; | | biblioserver | __RAW__ | gato | 2,gatoconbot-1;4,elgatoconb-3;7,las100cant-1; | | biblioserver | __RAW__ | yo | 2,gatoconbot-1;7,las100cant-1; | | biblioserver | __RAW__ | con | 2,gatoconbot-1;4,elgatoconb-3; | | biblioserver | __RAW__ | botas | 2,gatoconbot-1;4,elgatoconb-3; | | biblioserver | note | 90 | 2,gatoconbot-1; | | biblioserver | note | p | 2,gatoconbot-1;3,algunosjui-1;6,pepeelroma-1; | +--------------+-----------+-------+---------------------------------------- -------+ And a new entry added yesterday after all the nozebra rebuild process: +--------------+-----------+----------+--------------------------------+ | server | indexname | value | biblionumbers | +--------------+-----------+----------+--------------------------------+ | biblioserver | __RAW__ | 20071119 | 9,eljamónde-1;9,eljamóndej-1; | | biblioserver | __RAW__ | frey50 | 9,eljamónde-1;9,eljamóndej-1; | | biblioserver | __RAW__ | jamón | 9,eljamónde-1;9,eljamóndej-1; | | biblioserver | __RAW__ | jabugo | 9,eljamónde-1;9,eljamóndej-1; | +--------------+-----------+----------+--------------------------------+ Hope this helps to clarify something!. Thanks in advance, Ignacio -----Mensaje original----- De: Mason James [mailto:mason.james@liblime.com] Enviado el: martes, 20 de noviembre de 2007 3:34 Para: Ignacio CC: koha-devel@nongnu.org Asunto: Re: [Koha-devel] Advanced search Queries in Nozebra mode, via Nozebratable, queriying column named 'indexname', returning __RAW__ and failing in Search.pm On 2007/11/20, at 6:12 AM, Ignacio wrote:
I made the rebuild but there are still some rows that contain __RAW__ value and same for new catalog entries, they are stablishing a default value for indexname to the value '__RAW__' each time I add a a new entry to the catalog.
The basic search makes a 'value' column matching of this table, but advanced search filters make a more granular selection using parameters (title, subject, ISBN, etc...) that are matching against a __RAW__ value that seems being generated (instead title, subject, etc...) in nozebra table each time a new entry is catalogued.
The script seems to add some indexname = title, author, etc... entries, but does not fix raw entries added before.
It seems to be a problem inherited caused by misconfiguration. Some ideas?
Hiya Ignacio, Easy questions first :) What marc flavour are you using, UNIMARC or MARC21. ? I have been working on some MARC21 imports this week, and have found some little tricks, for MARC21 nozebra at least how does your nozebra table look if you run this sql?? heres mine. mysql> select distinct(indexname) from nozebra; +--------------+ | indexname | +--------------+ | author | | bc | | biblionumber | | date | | host-item | | isbn | | note | | subject | | title | | __RAW__ | +--------------+ 10 rows in set (0.03 sec)
participants (3)
-
Henri-Damien LAURENT -
Ignacio -
Mason James