Re: [Koha-devel] Zebra with ICU and startswithnt, first-in-subfield, etc.

2012-04-18 Thread Pongtawat Chippimolchai
I try both enable and disable QueryFuzzy, QueryWeightFields, QueryStemming and it seems to make no difference. For record.abs, I use the default one that came with Koha 3.2. I could post the file somewhere if it is needed. For Zebra, beside telling it to use ICU (icuchain words-icu.xml), I didn't

Re: [Koha-devel] A longer barcode

2012-04-18 Thread Paul Poulain
Le 18/04/2012 18:23, Zeno Tajoli a écrit : > Do you have experience on the topic ? IIRC, we already made that once (not 60, but 30 iirc), and got no specific problem I don't guarantee though, just trying to remember -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-do

[Koha-devel] A longer barcode

2012-04-18 Thread Zeno Tajoli
Hi to all, a library of us ask me to use barcode more long of 20 char. I think I need to change from 'barcode' varchar(20) NOT NULL, to 'barcode' varchar(60) NOT NULL, Clerly there are problems on OPAC and Intranet display (template are organized with a max barcode lenght of 20 chars). But in .p

Re: [Koha-devel] Koha performance enhancement overview

2012-04-18 Thread Fridolyn SOMERS
Hie, Frédéric, you are on my side. > It means that if we cache HTML representation of biblio records, we loose real-time items availability in OPAC result page You can't have a real-time AND performance. Can't a user have an item status old from few minutes ? It is already this with search engine

Re: [Koha-devel] Koha performance enhancement overview

2012-04-18 Thread Frédéric Demians
> Unless we're working with a small catalogue, or one with only a few > popular items, I'm not sure we'd get much benefit from caching the > XSLT-processed HTML for individual biblios. Outside of those cases, I > don't think a lot of people will be looking at the same records, so > we're just sto

Re: [Koha-devel] Koha performance enhancement overview

2012-04-18 Thread Ian Walls
Unless we're working with a small catalogue, or one with only a few popular items, I'm not sure we'd get much benefit from caching the XSLT-processed HTML for individual biblios. Outside of those cases, I don't think a lot of people will be looking at the same records, so we're just storing info u

Re: [Koha-devel] Koha performance enhancement overview

2012-04-18 Thread Chris Cormack
Check out redis too, very cool stuff. Chris Fridolyn SOMERS wrote: Ok, thanks, I have to learn more about memcached. 2012/4/17 Robin Sheat Fridolyn SOMERS schreef op ma 16-04-2012 om 16:13 [+0200]: > But it would need a huge quantity of RAM no ? Not nearly as much as you would think, reall

Re: [Koha-devel] Koha performance enhancement overview

2012-04-18 Thread Fridolyn SOMERS
Ok, thanks, I have to learn more about memcached. 2012/4/17 Robin Sheat > Fridolyn SOMERS schreef op ma 16-04-2012 om 16:13 [+0200]: > > But it would need a huge quantity of RAM no ? > > Not nearly as much as you would think, really. And it'll let the older > ones expire when things get full. >

Re: [Koha-devel] Zebra with ICU and startswithnt, first-in-subfield, etc.

2012-04-18 Thread Fridolyn SOMERS
Hie, First of all, what are the search preferences activated in your Koha: QueryWeightFields, QueyFuzzy, ... ? 2 : what is your config of Title index in record.abs ? 3 : I know that the use of "startswithnt" and "first-in-field" needs a configuration in Zebra before indexing. Did you customize som