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@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

Tél.  : (888) 604-2627
philippe.blouin@inLibro.com

inLibro | pour esprit libre | www.inLibro.com

_______________________________________________
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/
--
Tomás Cohen Arazi
Theke Solutions (https://theke.io)
✆ +54 9351 3513384
GPG: B2F3C15F