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

[Kyle Hall]

I think this sounds great! The one suggestion I would make is to try to
break this down into as many discretely testable bug reports a possible.
The smaller each testable unit is, the more easily tested and qa'd it is.

Kyle

<https://secure2.convio.net/cffh/site/Donation2?df_id=1395&FR_ID=4715&PROXY_ID=2706639&PROXY_TYPE=20&1395.donation=form1&s_src=CHORUS&s_subsrc=CHAADOEB>

http://www.kylehall.info
ByWater Solutions ( http://bywatersolutions.com )
Meadville Public Library ( http://www.meadvillelibrary.org )
Crawford County Federated Library System ( http://www.ccfls.org )

On Thu, Jul 21, 2016 at 3:30 PM, Philippe Blouin <
philippe.blouin at inlibro.com> wrote:

> 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>) 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 at inLibro.com
>> inLibro | pour esprit libre | www.inLibro.com
>>
>> _______________________________________________
>> Koha-devel mailing list
>> 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
>
>
>
> _______________________________________________
> Koha-devel mailing list
> 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160723/b9797f1e/attachment.html>