[Koha-devel] Reminder: General IRC meeting 13 January 2016

2016-01-12 Thread Katrin Fischer 
Hi all,

just a quick reminder of the Koha General IRC meeting on

13 January 2016 at 20:00 UTC

http://wiki.koha-community.org/wiki/General_IRC_meeting_13_January_2016

Hope to see you there :)

Katrin


___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Playing with NYTProf

2016-01-12 Thread Julian Maurice 
In the last part ("the real real life"), you say 30% of the time is take
by C4::Context::preference, but I don't see where this number comes
from. If I look at the flame graph of the "second profile"
(https://joubu.github.io/koha/nytprof/dbic/nytprofhtml.21326_2/)
C4::Context::preference only takes 2.42%
In the last profile (which is with your patch, right ?),
C4::Context::preference exclusive's time is bigger than any other
subroutines and we spend 9.22s (inclusive) inside
C4::Context::preference for "only" 283 calls, which seems huge.
So... maybe I don't understand correctly NYTProf output, or there is
something wrong with your patch

Le 11/01/2016 15:57, Jonathan Druart a écrit :
> Hi devs,
> 
> I have played with NYTProf at the end of the last week, here is my
> loosely structured notes:
> https://joubu.github.io/koha/nytprof/dbic/index.html
> 
> I have not found big things to implement in order to improve the speed
> but I am wondering if there is not something wrong with the queries
> cache (Search in the page for "Update:")
> 
> Hope to get some feedbacks.
> 
> Cheers,
> Jonathan
> 
> PS: If someone has a better idea to share the profiles, I am open-minded.
> ___
> Koha-devel mailing list
> Koha-devel@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/
> 


-- 
Julian Maurice 
BibLibre
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Hide records on Leader 05 = d in OPAC

2016-01-12 Thread Galen Charlton 
Hi,

On Sun, Jan 10, 2016 at 8:44 PM, David Cook  wrote:
> We can’t necessarily rely on all Koha instances running this cronjob, nor
> can we rely on the frequency. Shouldn’t we be hiding these records from the
> OPAC as soon as they’re marked as “deleted”?
>
> I’ve opened a bug for this purpose:
> http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15537

I am in mild disfavor of this proposal, particularly as implemented in
current patch. Using a cronjob to delete records where Leader/05 is
set to 'd' is useful when the library has arranged their workflow such
that they *know* that Leader/05 = 'd' is being used consistently to
signify that a record is no longer wanted. However, for a library that
has not hitherto cared about the values in that position,
unconditionally suppressing the display of such records could come as
an unwelcome surprise.

That said, it is also a reasonable choice for a library to want to use
the Leader/05 as suppression criterion.  Consequently, I suggest
adding a configuration option.  For that matter, making it
configurable (say, by allowing the library to specify a set of query
additions for the purpose of filtering records from public display)
could result in a more generally useful mechanism.

> I admit that I have a special interest in this where I might
> be overlaying existing records using a mostly empty skeleton
>  record generated from an OAI-PMH identifier and a OAI-PMH
> deleted status (OAI-PMH doesn’t send metadata for deleted records).
>  I’d match the existing record in Koha using the identifier, and
> then set LDR05 to “d” in accordance with the OAI-PMH deleted
> status. Then, that record would disappear from the OPAC, so that
> end users don’t see this skeleton record.

I do not find this a compelling use case as stated.  If the goal is to
allow harvesting and overlay records from an OAI-PMH provider to also
delete bibs from a Koha database... coding so that the records are
*actually* deleted seems more direct.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@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
___
Koha-devel mailing list
Koha-devel@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] Which version of Zebra in Debian Jessie?

2016-01-12 Thread Zeno Tajoli 
Hi to all,

testing the install of Koha oldstable (3.20.7.1 now) with packaging I find this
problem about version of Zebra:

1)If I create only /etc/apt/sources.list.d/koha.list with
deb http://debian.koha-community.org/koha oldstable main

I install Zebra from debian jessie repo, so version 2.0.59
with the problem "ICU phrase searches for terms split by ICU ZEB-664"

2)If I add /etc/apt/sources.list.d/indexdata.list with
deb http://ftp.indexdata.dk/debian jessie main

The sistem try to install zebra 2.0.61 with new yaz lib (5.15.2)
This version of yaz doesn't work with package libnet-z3950-zoom-perl,
the essential package for search and cataloguing.

So, do you have fund this problem ?
Do you think that the only solution now is to install zebra 2.0.59 on Debian 
Jessie ?

Bye
Zeno Tajoli
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Playing with NYTProf

2016-01-12 Thread Jonathan Druart 
Hi Julian,
On the second profile of the real real life (nytprofhtml.21326_2), you
can see the 30% on the flame graph.
Search for 'Update' on the page, there is something I done understand.
The queries don't look to be cached (what I was expecting).


2016-01-12 8:16 GMT+00:00 Julian Maurice :
> In the last part ("the real real life"), you say 30% of the time is take
> by C4::Context::preference, but I don't see where this number comes
> from. If I look at the flame graph of the "second profile"
> (https://joubu.github.io/koha/nytprof/dbic/nytprofhtml.21326_2/)
> C4::Context::preference only takes 2.42%
> In the last profile (which is with your patch, right ?),
> C4::Context::preference exclusive's time is bigger than any other
> subroutines and we spend 9.22s (inclusive) inside
> C4::Context::preference for "only" 283 calls, which seems huge.
> So... maybe I don't understand correctly NYTProf output, or there is
> something wrong with your patch
>
> Le 11/01/2016 15:57, Jonathan Druart a écrit :
>> Hi devs,
>>
>> I have played with NYTProf at the end of the last week, here is my
>> loosely structured notes:
>> https://joubu.github.io/koha/nytprof/dbic/index.html
>>
>> I have not found big things to implement in order to improve the speed
>> but I am wondering if there is not something wrong with the queries
>> cache (Search in the page for "Update:")
>>
>> Hope to get some feedbacks.
>>
>> Cheers,
>> Jonathan
>>
>> PS: If someone has a better idea to share the profiles, I am open-minded.
>> ___
>> Koha-devel mailing list
>> Koha-devel@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/
>>
>
>
> --
> Julian Maurice 
> BibLibre
> ___
> Koha-devel mailing list
> Koha-devel@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@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/