> As another example, you have a fully parsed MARC::Record object
> representation for a given biblio. You can store that object away,
> and the next time you need to reference it (when a user clicks for the
> details page, or the MARC page, etc.) you can retrieve and use it
> without having
On Wed, Feb 4, 2009 at 5:50 PM, Rick Welykochy wrote:
> Of course, a cache is pretty useless unless perl itself is cached using
> mod_perl or similar.
Although I agree the ORM layer really accelerates how quickly you can get
benefit out of memcached, it is certainly incorrect that mod_perl is
r
Joe Atzberger wrote:
> While it is the obvious "core" of DB access in Context, it is not the
> only target for memcached efficiency, in my mind. That is because the
> access is rather straight-forward retrieving preferences (that are
> already cached for the process by Koha).
>
> To me, the
February 3, 2009-- The creators and developers of Koha, the first open
source Integrated Library System (ILS), today announced that KohaCon
2009-- a conference for current and interested users of the Koha
Integrated Library System--- will be held in Plano, Texas, April 16 &17,
2009.
KohaCon 20
2009/2/3 Dan Scott :
> 2009/2/3 Joshua Ferraro :
>> On Tue, Feb 3, 2009 at 7:12 AM, MJ Ray wrote:
>>> Dan Scott wrote:
I'm curious about the divergence of the SIP code between the Koha and
OpenNCIP code bases. [...] IANAL, but the
providence of the OpenNCIP code should probably be
While it is the obvious "core" of DB access in Context, it is not the only
target for memcached efficiency, in my mind. That is because the access is
rather straight-forward retrieving preferences (that are already cached for
the process by Koha).
To me, the best targets are the sections that req
John Beppu a écrit :
> I agree that it was quite a disappointment to only see about 10%
> improvement in the request rate despite eliminating so many database
> queries. I was expecting a much bigger speed increase, too.
my bet is that C4::Context cleaning will be the best improvement source.
A
I agree that it was quite a disappointment to only see about 10% improvement
in the request rate despite eliminating so many database queries. I was
expecting a much bigger speed increase, too.
If you want to benchmark it yourself, here's how I ran apache bench against
koha:
ab -H "Cookie: CGISE
No problem. I'll use the word "undo" the next time I do something like
that. I'm still kind of a n00b to this code base, so it'll probably happen
again.
--beppu
On Wed, Feb 4, 2009 at 1:57 AM, MJ Ray wrote:
> John Beppu wrote:
> > This was also my first encounter with the messaging system, a
Sure.
The purpose of this big set of patches was to make it possible for koha to
send notifications to borrowers upon checkout and check-in.
Next, you might be wondering why this seemingly simple task took 17 patches
to accomplish. ;-)
First, the high number of patches reflects the back and for
John Beppu wrote:
> This was also my first encounter with the messaging system, and I was trying
> to figure out what was going on. I was just undoing something that I
> shouldn't have even done in the first place. No real functionality
> disappeared as a result of this.
OK and thanks for the e
Hi John
Thanks for clarification.
It would be great to have a summary or a link to RFC in your patches,
so that we can better catch the general purpose of and the general
architecture implied by the handfull of patches sent, just as you have
just done for memcached (great by the way, even thou
This is probably not what you think it is. It's not like we're removing RSS
feeds from the entire system. We're actually just removing UI elements for
a messaging system feature that never even existed.
To clarify what happened, please run this query on your system:
SELECT * FROM message_transp
Can someone point me at the reasoning for removing RSS features from
the user interface, please? Are they currently broken and, if so,
where's the bug report?
Thanks,
--
MJ Ray (slef)
Webmaster for hire, statistician and online shop builder for a small
worker cooperative http://www.ttllp.co.uk/
14 matches
Mail list logo
