<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 07/21/2016 02:23 PM, Tomas Cohen Arazi wrote:<br>
<blockquote
cite="mid:CABZfb=W8YXdmjuPUXE_Wub5yZZvo4JoohNBuJJtBmDRhCczndw@mail.gmail.com"
type="cite">
<div dir="ltr">I'm all for speed improvements. But:
<div>- A clear backwards-compatible upgrade path needs to be set
and written.</div>
</div>
</blockquote>
Our curent script takes the content of the "old" tables to create
the new one. Past and future. Is that what you mean?<br>
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".<br>
<blockquote
cite="mid:CABZfb=W8YXdmjuPUXE_Wub5yZZvo4JoohNBuJJtBmDRhCczndw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>- 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.</div>
</div>
</blockquote>
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...<br>
<br>
SELECT COUNT(*) FROM discrete_calendar WHERE (date BETWEEN ? AND ?)
AND (isopen=1)<br>
<br>
Add in opening and closing hours and it's golden. Easily hashable
and cachable as well.<br>
<br>
<blockquote
cite="mid:CABZfb=W8YXdmjuPUXE_Wub5yZZvo4JoohNBuJJtBmDRhCczndw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>- 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.</div>
</div>
</blockquote>
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.<br>
<br>
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...<br>
<blockquote
cite="mid:CABZfb=W8YXdmjuPUXE_Wub5yZZvo4JoohNBuJJtBmDRhCczndw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Regards</div>
</div>
</blockquote>
Thanks a lot for the feedback!<br>
<br>
<blockquote
cite="mid:CABZfb=W8YXdmjuPUXE_Wub5yZZvo4JoohNBuJJtBmDRhCczndw@mail.gmail.com"
type="cite"><br>
<div class="gmail_quote">
<div dir="ltr">El jue., 21 jul. 2016 a las 13:43, Philippe
Blouin (<<a moz-do-not-send="true"
href="mailto:philippe.blouin@inlibro.com">philippe.blouin@inlibro.com</a>>)
escribió:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> Hi!<br>
<br>
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.<br>
<br>
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.<br>
The reasonning being:<br>
- We need the opening hours. They need to vary season to
seasons. We need them for hourly and minute loans.<br>
- Exception and holidays and etc... are complicated. To
manage, to calculate, to fix. We need the past info as
well, to calculate precisely.<br>
- Performance. Calculating with C4/Koha Calendars is
sloooooooooow. Our little table cut <a
moz-do-not-send="true" href="http://fines.pl"
target="_blank">fines.pl</a> calculation times by 97%.
Not a typo. Checkout improvement by 30-60% but metric is
unreliable so take with grain of salt this one.<br>
<br>
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? <br>
<br>
All comments, suggestions, questions are welcomed.<br>
<br>
High regards,<br>
<br>
<div>
<div>
<div> <span>Philippe Blouin,</span><br>
<span>Responsable du développement informatique</span><br>
<p> Tél. : (888) 604-2627<br>
<a moz-do-not-send="true"
href="mailto:philippe.blouin@inLibro.com"
target="_blank">philippe.blouin@inLibro.com</a> </p>
</div>
<div> <span>in</span><span>Libro</span> <span>| pour
esprit libre |</span> <a moz-do-not-send="true"
href="http://www.inLibro.com" target="_blank">www.inLibro.com</a>
</div>
</div>
</div>
<br>
</div>
_______________________________________________<br>
Koha-devel mailing list<br>
<a moz-do-not-send="true"
href="mailto:Koha-devel@lists.koha-community.org"
target="_blank">Koha-devel@lists.koha-community.org</a><br>
<a moz-do-not-send="true"
href="http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel"
rel="noreferrer" target="_blank">http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel</a><br>
website : <a moz-do-not-send="true"
href="http://www.koha-community.org/" rel="noreferrer"
target="_blank">http://www.koha-community.org/</a><br>
git : <a moz-do-not-send="true"
href="http://git.koha-community.org/" rel="noreferrer"
target="_blank">http://git.koha-community.org/</a><br>
bugs : <a moz-do-not-send="true"
href="http://bugs.koha-community.org/" rel="noreferrer"
target="_blank">http://bugs.koha-community.org/</a></blockquote>
</div>
<div dir="ltr">-- <br>
</div>
<div data-smartmail="gmail_signature">
<div dir="ltr">
<div style="color:rgb(117,117,117);font-family:'helvetica
neue',helvetica,arial,sans-serif;font-size:12.8px">Tomás
Cohen Arazi</div>
<div style="color:rgb(117,117,117);font-family:'helvetica
neue',helvetica,arial,sans-serif;font-size:12.8px">Theke
Solutions (<a moz-do-not-send="true" href="http://theke.io/">https://theke.io</a>)<br>
✆ +54 9351 3513384<br>
GPG: B2F3C15F</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>