<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>A little more information. I've lifted the cover and peeked at
the data tables in the sqlite database.</p>
<p>It looks like I have several 'requests' with "Expiry" values of
4080127620 and 4083327900. If my epoch calculations are correct,
those are <span title="Fri Apr 17 2099 08:47:00 GMT-0800 (Alaska Daylight Time)">April
17, 2099 and </span><span title="Sun May 24 2099 09:45:00 GMT-0800 (Alaska Daylight Time)">May
24, 2099 So I suppose it is little wonder that the reaping
process hasn't cleaned them out. It is interesting that they all
have the same "SrcEmail", and were created at 1713286033 and
1716486355 (</span><span title="Tue Apr 16 2024 08:47:13 GMT-0800 (Alaska Daylight Time)">April
16, 2024 and </span><span title="Thu May 23 2024 09:45:55 GMT-0800 (Alaska Daylight Time)">May
23, 2024). It kind of looks like they were assigned a 75-year
lifetime.</span></p>
<p><span title="Thu May 23 2024 09:45:55 GMT-0800 (Alaska Daylight Time)">And
it looks like that is just an editable number in the 6.05 web
interface. "Drop-off must occur between XXX and YYY", and the
fields are user-editable with no limits. Where the 6.13
interface has a nice little calendar control, managed by the new
'maxRequestEndDays' setting. So my user in April was tricky, and
simply changed the '2024' in that text box to '2099', giving me
entries in my 'reqtable' which the reaper will never act on.</span></p>
<p><span title="Thu May 23 2024 09:45:55 GMT-0800 (Alaska Daylight Time)">It
looks like in 6.13, 'Requests' can be deleted from the "Global
Drop-off List" in the same way that 'Dropoffs' can be deleted in
6.05. <br>
</span></p>
<p><span title="Thu May 23 2024 09:45:55 GMT-0800 (Alaska Daylight Time)">So
my hunch is, I can proceed with my 6.05 --> 6.13 update. And
when it is done, I can use the "Global Drop-off List" to select
and delete those long-lived 'requests'.<br>
</span></p>
<pre class="moz-signature" cols="72">--
Do things because you should, not just because you can.
John Thurston 907-465-8591
<a class="moz-txt-link-abbreviated" href="mailto:John.Thurston@alaska.gov">John.Thurston@alaska.gov</a>
Department of Administration
State of Alaska</pre>
<div class="moz-cite-prefix">On 11/13/2024 7:44 AM, John Thurston
via ZendTo wrote:<br>
</div>
<blockquote type="cite" cite="mid:WM!f1759e43ce88534e41404afbac0cecfefd1ce8833281cf7c3750a872930caa453eaf5620b0136a513a382a5dcaa3d730!@mx.jul.es">
<div>
<p>I can see what you mean when I look at my new-to-me 6.13
test-installation. Thank you for the guidance.<br>
</p>
<p>On that system, after I make a 'request', the "Global
Drop-off List" has similar looking numeric "Claim ID" (e.g.
"828 320 622") and the word "Request" in the "Size" column.
Interestingly, the 'requests' are shown with yellow
backgrounds in the table cells.<br>
</p>
<p>On the system I updated from 6.05 --> 6.13, the numeric
entries appeared with "0" (zero) in the "Size" column (rather
than the word "Request"). And they appeared in the same table
color-scheme as all of the drop-offs.</p>
<p>On that system, the entries carried dates ranging from
20240416 --> 20241112 (our requests should expire after 7
days). They all appeared with numeric "Claim ID", "0" in the
"Size", and with no distinctive background. So my concerns
here are:</p>
<ul>
<li>Some parts of the code recognize them as Requests, other
parts seem not to</li>
<li>New Requests must be stored differently than old
instances, as they are displayed differently in the Global
List</li>
</ul>
<ol>
<li>Will these Old Requests (which display differently),
behave as expected?</li>
<li>Will the ancient Requests now be caught by the reaper?</li>
</ol>
<p>I can live with yes or no for either question. I'd like to
know what to tell my customers to expect.<br>
</p>
<pre class="moz-signature" cols="72">--
Do things because you should, not just because you can.
John Thurston 907-465-8591
<a class="moz-txt-link-abbreviated moz-txt-link-freetext" href="mailto:John.Thurston@alaska.gov" moz-do-not-send="true">John.Thurston@alaska.gov</a>
Department of Administration
State of Alaska</pre>
<div class="moz-cite-prefix">On 11/13/2024 6:51 AM, <a class="moz-txt-link-abbreviated moz-txt-link-freetext" href="mailto:jules@zend.to" moz-do-not-send="true">
jules@zend.to</a> wrote:<br>
</div>
<blockquote type="cite" cite="mid:WM!dcc975368e601bcf716a84e0f80a930173d1d2837150d8be0497b41758551b463c6799bd7e5baaf5d3df95c11b91875a!@mx.jul.es">
<div>The ones with the numeric values should be labelled as
"requests" in one of the other columns. They are
requests-for-dropoffs, not dropoffs themselves. They should
get cleared up like they have been in the past, it's just
now they show in that table.<br>
<br>
Cheers,<br>
Jules.<br>
<br>
<br>
<div class="moz-cite-prefix">On 13/11/2024 3:25 pm, John
Thurston via ZendTo wrote:<br>
</div>
<blockquote type="cite" cite="mid:WM!b31340de06823061d684645fb87396d055473ff22d4910e54a3b3ffeaa64dc53f4e1d809f9cf482bad6334b743bddd3b!@mx.jul.es">
<p>Updating our test-system seemed to work perfectly. Not
so for production.</p>
<p>After updating from 6.05-4 to 6.13-3, I have some
strange behavior (and have reverted to the old, by way
of a VMWare snapshot).</p>
<p>New drop-off and pickup seems to work as expected.
Picking up recent drop-offs seemed to work as expected.
But the "Show All Drop-offs" now contains some entries
with numeric values (e.g. "235 637 597") in place of the
expected strings (e.g. "22iUmVdjs9WxszxD"). I exported
all of the drop-offs to a CVS. All of the numeric
clamIDs show a zero size. And most of them are well past
their expiration date. Most are only a little old, but
some are more than 6-months old.</p>
<p>So I <i>suspect</i> there are some old entries in the
database which weren't cleaned up in the normal course
of operations. The new code in 6.13 is finding them,
interpreting them, and adding them to the list of
available downloads. I also
<i>suspect</i> that the next reaping through the
database by the new code would clean them out.</p>
<p>But I couldn't be sure, so I've reverted to 6.05 while
I try to figure out what it is doing and if it is safe.</p>
<p>I know that 6.13 is now a couple of years old, so
others probably performed their update in the distant
past. But does anyone have any insight or advice?</p>
<br>
</blockquote>
</div>
</blockquote>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
ZendTo mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ZendTo@zend.to">ZendTo@zend.to</a>
<a class="moz-txt-link-freetext" href="http://jul.es/mailman/listinfo/zendto">http://jul.es/mailman/listinfo/zendto</a>
</pre>
</blockquote>
</body>
</html>