At 03:30 PM 7/21/2016 -0400, Philippe Blouin wrote:
On 07/21/2016 02:23 PM, Tomas Cohen Arazi wrote:
I'm all for speed improvements. But:
[snip]
- I think (because of the speed improvement) that you are realying more
on the DB features, this needs to be discussed if it can cause trouble.
Actually, that's the serious point: we're going simple SELECTs the old
way. With no cache or anything right now. It's not the fact that the
code is cut by 80% or anything (although it would be). It's just that
much faster to do date calculations using the DB than Perl's DateTime.Â
Just some thoughts, because I do not know where Koha is with MySQL 5.7
which is appreciably faster than 5.5/5.6 (we have, without trouble, got
Koha 3.08 up and running -- but have had no luck updating to the 16.05 db
structure on 5.7 and I haven't had time to look into the deltas.) Oracle
claims a 3x improvement in read-only speed, our testing confirms it...
However, +1 for Philippe's train of thought. I have always favoured direct
interrogation of the db rather than bifurcating through various libraries
unless the "value added" is incontrovertible. But backwards compatibility
(or at least flaw-free updating scripts) for an open-source project as
important as Koha must be considered.
As to calendars, these are a pet peeve with my employees and volunteers --
we have them all over the place, google maps, facebook, yellow pages, our
own website, numerous community links (probably more that I can't remember,
or are "copied" by other services e.g. bing maps appears to copy google
maps) so we would not be looking for yet another one to manage. But if
that's what the Koha community wants, there's no objections from me :=}
Best -- Paul
Something like...
SELECT COUNT(*) FROM discrete_calendar WHERE (date BETWEEN ? AND ?) AND
(isopen=1)
Add in opening and closing hours and it's golden. Easily hashable and
cachable as well.
- The less you change the API, the easier is to spot regressions for the
current blacklist-like implementation of the calendar. Tests could be
adjusted, but it'd be interesting to have the current tests pass.
I agree. I admit I do not have a clear plan, and I know without perfect
test coverage, this stands no chance. More so, wasting perfectly valid
old tests is... a waste.
But again, I'm throwing a line. I want to see if others beside us see a
need. I want to see if someone is already working on something that
would conflict, etc...
Regards
Thanks a lot for the feedback!
El jue., 21 jul. 2016 a las 13:43, Philippe Blouin
(<philippe.blo...@inlibro.com>) escribió:
Hi!
I'm throwing a line here, and I'd just like to get a feel for the value
of offering some work to the community. Mind you, the work is "big" so
honest responses could save us lot of wasted hours.
We've developed a parallel calendar table to specify each individual day
if it's opened or not (instead of rules and exception). We added to it
the opening hours, and keep a year of them in the past, and a year in the
future.
The reasonning being:
- We need the opening hours. They need to vary season to seasons. We
need them for hourly and minute loans.
- Exception and holidays and etc... are complicated. To manage, to
calculate, to fix. We need the past info as well, to calculate precisely.
- Performance. Calculating with C4/Koha Calendars is
sloooooooooow. Our little table cut fines.pl calculation times by
97%. Not a typo. Checkout improvement by 30-60% but metric is
unreliable so take with grain of salt this one.
So before I go and write a wiki RFC, then open bugzillas, make the code
community acceptable (we're not using Schemas), complete it, write tests,
etc... Is there an interest? Would it answer a need (outside of our
clients) ? Maybe a subset?Â
All comments, suggestions, questions are welcomed.
High regards,
Philippe Blouin,
Responsable du développement informatique
_______________________________________________
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/
