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.blo...@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.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 >> >> Tél. : (888) 604-2627 >> philippe.blo...@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 <http://theke.io/>) > ✆ +54 9351 3513384 > GPG: B2F3C15F > > > > _______________________________________________ > 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/ >
_______________________________________________ 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/