Hi All
I'm delighted to send this mail (on behalf of the organising team) to
let people know we are now accepting general sponsorships for Kohacon12,
by bank transfer or paypal/card.
http://koha-community.org/kohacon12/sponsoring-kohacon12/
As you probably all know Kohacon is a free conference a
Hi All
I'm delighted to send this mail (on behalf of the organising team) to
let people know registrations for Kohacon12 are now open.
http://koha-community.org/kohacon12/registration/
As you probably all know Kohacon is a free conference but we do need
people to preregister so we have ideas of
Hello koha-devel,
Reminder : the string freeze will be declared on monday.
I've QAed & pushed all patches that were in "signed-off" status (except
some 4 new features submitted by BibLibre that will wait for next
release), but I'd like to point that the bug 2780 contains a *lot* of
patches that I
I will try to include answers to all questions which where addressed to
me in thread in this single message. If I missed something, sorry :-)
I played around the code a bit more (and plan to spend a few more days on it
to have some idea how much of the *measurable* change it will make), but I
will
Zeno,
> Probaly not a pure CCL but something very similar to the present opac
> queries that are so:
>
> idx=ti,phr
> &q=red+winter
> &op=and
>
> &idx=au,wrdl
> &q=white
> &op=and
>
> &idx=kw
> &op=and
>
> &idx=kw
>
> &sort_by=call_number_asc&do=Search
>
If we're using that we could just as easi
Hi,
Il 06/04/2012 13:27, Jared Camins-Esakov ha scritto:
> I disagree. As it stands now, CCL is not an acceptable alternative to PQF.
> CCL can be ambiguous, and runs into all sorts of problems with quoting,
> etc.
Probaly not a pure CCL but something very similar to the present opac
queries tha
Le 06/04/2012 12:40, Chris Cormack a écrit :
>> Am I right if I say that the 1st technique is the best and is what is
>> achieved by ->flush_cache() method of (memoize::)memcached ?
>
> The third option, and best option imho is when a value is change, it
> is injected into the cache at that point.
I disagree. As it stands now, CCL is not an acceptable alternative to PQF.
CCL can be ambiguous, and runs into all sorts of problems with quoting,
etc. The only way I can see a CCL-style query language being a viable
option for all searching would be if Koha had a new search parser that was
well-de
2012/4/6 Ian Walls :
> Would it be practical and efficient to cache shared data to file (or a
> series of files)? My understanding is that reading files is faster than
> doing SQL queries, but not as fast as accessing memcached. But, the file
> would have the advantage of being non-threaded. I d
>
> As you're experimented in caching, a question: I think cache
> invalidation can be made by 2 different techniques:
> * when a data make the cache invalid, it send a message to all cache to
> say "hey, cache is reseted". Cache is reseted, and next time a data is
> requested it won't be in the ca
Le 06/04/2012 12:08, Frédéric Demians a écrit :
> Dobrica Koha::Persistant module make sense to me. It has thread
> in-memory caching now, but can be extended to implement multi-thread
> in-memory or in memcached (or redis, MySQL...) caching. The question is
> more: is it necessary to mix caching
Would it be practical and efficient to cache shared data to file (or a
series of files)? My understanding is that reading files is faster than
doing SQL queries, but not as fast as accessing memcached. But, the file
would have the advantage of being non-threaded. I don't think
configuration thin
Le 06/04/2012 10:14, Chris Cormack a écrit :
>> The memcached is a workaround according to me: it put the result in a
>> memcached server, so doesn't care of the fact that the CGI dies, but the
>> price of reaching the page is very high, limiting the gain (chris_c said
>> many times that memcached
Since Koha is a multi-threading app, with or without Plack, caching is
not that easy. There is already some caching but at thread level.
Memcached can be a solution for sharing cached data structure (like
framework for example) between threads, and even between threads running
on multiple servers.
Apologies, Dobrica, not Dobrika. :)
___
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 : ht
On 5 April 2012 23:20, Paul Poulain wrote:
> Le 04/04/2012 17:48, Dobrica Pavlinusic a écrit :
>> I would like to propose new module which would keep track of all
>> persistant values for rest of Koha code.
> Hi Dobrika,
>
>> As opposed to C4::Cache* which never got implemented in all code,
>> I p
Am 06.04.12 09:58, schrieb Paul Poulain:
> Le 06/04/2012 09:43, Fridolyn SOMERS a écrit :
>
>> In conclusion, I'd say that the problem should be cured at its source.
>> I mean that the number of SQL queries and cache systems should be
>> optimized in Koha code.
> +1000 = the problem shoud be cured
Le 06/04/2012 09:43, Fridolyn SOMERS a écrit :
> In conclusion, I'd say that the problem should be cured at its source.
> I mean that the number of SQL queries and cache systems should be
> optimized in Koha code.
+1000 = the problem shoud be cured at its source, and that's the goal of
the thread
I agree,
CCL for all search engines.
Some PQF queries exiting in Koha (in authorities search for example) can
easily be converted in CCL.
On Thu, Apr 5, 2012 at 5:52 PM, Zeno Tajoli wrote:
> Hi to all,
>
> Il 30/03/2012 18:15, Paul Poulain ha scritto:
> >
> > As you know, our main goal for the
Hie,
You have to consider it with the number of users connected at the same time.
For earch user connected :
MySQL server will require some CPU, a lot of RAM and some hard disk
performance.
Apache will need good CPU performance (to execute Perl).
So it depends on your hardware.
If you have simpl
20 matches
Mail list logo
