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 <mailto: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 <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.blo...@inlibro.com <mailto:philippe.blo...@inlibro.com>
inLibro | pour esprit libre | www.inLibro.com
<http://www.inLibro.com>
_______________________________________________
Koha-devel mailing list
Koha-devel@lists.koha-community.org
<mailto: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/
