Open mcast opened 2 years ago
(@kript: sorry I didn't get this in for the meeting last week. The local interrupt generator is not maskable.)
Data objects to not have timestamps.... replicas have timestamps.
Does that shift your mental model enough that a solution to your needs/assumptions presents itself?
You trimmed the original replica, so the original timestamp is now gone. You could always attach an AVU (at the data object level) with markings/timings of your choosing.
On Tue, Oct 25, 2022 at 09:03:11AM -0700, Terrell Russell wrote:
Data objects to not have timestamps.... replicas have timestamps.
Does that shift your mental model enough that a solution to your needs/assumptions presents itself?
That's pretty much where it had shifted to: the built-in metadata cannot answer my question. I was looking at "how much data used in the last year?" for purchase forecasts, and due to the irepl/itrim runs for hardware refresh I got two very different answers.
What remains is a name which I found misleading, plus a lack of documentation to avoid the confusion before finding out the hard way.
If it were called REPLICA_CREATE_TIME then I would expect it.
If it were called FILE_CREATE_TIME then I think the current behaviour would be clearly incorrect.
In the absence of other guidance the name DATA_CREATE_TIME lands somewhere between; then the existence of DATA_MODIFY_TIME suggests there is more complex behaviour available.
What is the difference between DATA_CREATE_TIME and DATA_MODIFY_TIME ? I've never noticed them different but we don't do anything exciting with our pebibytes.
You trimmed the original replica, so the original timestamp is now gone.
Yes, this was done to the earliest bunch of files - stored 5 years ago.
You could always attach an AVU (at the data object level) with markings/timings of your choosing.
Fortunately we do that, indirectly, and it's how I got two different answers.
We have an AVU on each file which is foreign key to an external (LIMS) database table. The PK is monotonic-ish, the way sequences are with caching, and in the table we record file creation time.
(( Re: the script attached to OP, we don't leave a replica in the
"purple tree" after doing those operations. In the production
process, resources for hardware refresh are renamed from (red
xor
green
) to purple
. This causes irepl
onto the necessary colour
to return to 1 red + 1 green; then the purple are sent to the
retirement pasture / glue boiler. ))
-- The Wellcome Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.
Agreed on all counts - the attrs token name takes its name from the table in which it needs to be linked/found.
r_data_main
-> DATA_CREATE_TIME
If the data object table was split from the replica table... then yes, this would have been clearer.
So, for now, yes, your workaround/solution seems the best without an explicit timestamp AVU getting minted upon initial upload.
I'll leave this issue open as 'documentation' for us to think through describing in more detail the iquest attrs
tokens.
Thanks @trel
I'm working on adding a GenQuery page here: https://github.com/irods/irods_docs/pull/251 We can add explanations to the GenQuery attributes as a next step.
Feature
To the extent that this is a feature request,
iquest attrs | grep TIME
attributes mean.iput
, and for that to be preserved across (most?) other operations.I thought I had that so I'm going to continue as for a bug -
OR
Bug Report
iRODS Version, OS and Version
Ubuntu 18.04.6 LTS (bionic), iRODS Version 4.2.7
What did you try to do?
I tried to use
DATA_CREATE_TIME
as a time indicating when the file wasiput
.In between the
iput
and my question, there have been multipleirepl
/itrim
operations.This shellscript illustrates the issue,
The
sleep
s are just to space the timestamps out enough to be clearly distinguishable.Expected behavior
I expected one of the times shown in the first
iquest
output to continue to be available in the secondiquest
.If there is such a time value stored, please can it be documented more clearly?
Observed behavior (including steps to reproduce, if applicable)
Complications
I didn't get into
imv
or anything which might modify the contents of the file.