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

[Philippe Blouin]

On 07/21/2016 02:23 PM, Tomas Cohen Arazi wrote:
> I'm all for speed improvements. But:
> - A clear backwards-compatible upgrade path needs to be set and written.
Our curent script takes the content of the "old" tables to create the 
new one.  Past and future.  Is that what you mean?
More so, I've split the work in 8 theoretical steps.  But I think it 
could be considered to offer both ways in parallel: just add the new DB 
table, slowly transfer the calls to the new library.  Just make sure the 
new table is populated on any call to modify the "old ones".
> - 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.  
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 <mailto: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 <http://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
>
>     Tél.  : (888) 604-2627
>     philippe.blouin at inLibro.com <mailto:philippe.blouin at inLibro.com>
>
>     inLibro | pour esprit libre | www.inLibro.com
>     <http://www.inLibro.com>
>
>     _______________________________________________
>     Koha-devel mailing list
>     Koha-devel at lists.koha-community.org
>     <mailto:Koha-devel at 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/
>
> -- 
> Tomás Cohen Arazi
> Theke Solutions (https://theke.io <http://theke.io/>)
> ✆ +54 9351 3513384
> GPG: B2F3C15F

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160721/44e64af8/attachment.html>