[Koha-devel] Pre-RFC on new discrete calendar

[Paul A]

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.blouin at 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