[Koha-bugs] [Bug 17941] CanBookBeRenewed is very inefficient/slow

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Wed Feb 8 12:58:22 CET 2017


https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17941

Alex Sassmannshausen <alex.sassmannshausen at ptfs-europe.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alex.sassmannshausen at ptfs-e
                   |                            |urope.com

--- Comment #10 from Alex Sassmannshausen <alex.sassmannshausen at ptfs-europe.com> ---
Hello,

This looks like a really interesting hack! Thanks for sharing :-)

In terms of using it in Koha, I have some questions:

- Documentation for Attributes mentions it is experimental and the internal API
may change.  We may need to consider whether this is a risk for Koha?  Does
anyone know what the status is on that?
(http://perldoc.perl.org/attributes.html)

- I too, like Jonathan, worry slightly about Plack implications.  It may just
be that I don't quite understand how long the cache exists — but it seems to me
that in a Plack context the cache that is created by memoization here would not
be busted.  This would be problematic as follows:

 + GetMember memoizes a call to a specific borrowernumber
 + Another user in Plack updates the borrower details
 + Next call to GetMember returns memoized result, not the updated result.

How is the cache expired?

It could be that Plack in CGI compatibility mode does the expiring for us, so
it might work well in practice — Petter could you confirm whether you tested
this kind of use-case or similar ones?

To be specific, some of the calls that are Memoized are only Idempotent in the
context of no other db updates happening.  In CGI context, this is no problem. 
In long-living Plack processes this *may* be a problem.

Anyway, like I say — love the optimization! :-D

Alex

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are watching all bug changes.


More information about the Koha-bugs mailing list