Metadata timestamps returned for objects and collections

[paulborgermans]

When querying <data_object|collection>metadata(timestamps=True).items() it returns the timestamps from the avu creation, not when it was added to an item (the timestamps in the r_objt_metamap table for example).

Could this be specified in the query / future API calls or is there another way to obtain those timestamps with GenQuery / GenQuery2 ?

Thanks

[paulborgermans]

Bacground: we want to use those timestamps in workflow/validation scenarios

[d-w-moore]

Hmm, there don't seem to be any GenQuery1 columns that reflect the timestamp of AVU attachment (ie set/add). The META_*_MODIFY_TIME and META_MET2_MODIFY_TIME, in my experimentation , seem to reflect the the creation (or modification) of the AVU itself. Maybe GenQuery2 expands available columns to include the timestamps in the r_objt_metamap table, which do seem to reflect the attachment-ts values we're looking for? @korydraughn ?

[d-w-moore]

If not , I guess specific query will be the workaround / answer. In that case though, baking it into the PRC as a fixture, ie object attribute, will only be appropriate if these columns are available by means of a built-in (non-deletable) specific query.

[korydraughn]

@d-w-moore is correct. That information is not exposed through GenQuery1 or GenQuery2 today.

The only way to fetch that information is by using a SpecificQuery.

I'll open an issue in irods/irods for this.

[alanking]

So, we need to...

• Implement this: Expose create_ts and modify_ts columns in R_OBJT_METAMAP table through GenQuery irods#7889
• Use the new columns in PRC
• Decide what we want to do for PRC talking to servers older than 4.3.4 (or whatever version in which the new columns are exposed)
• Possibly document a SpecificQuery workaround which can get this information or even make an interface for it?

Am I missing anything?

[d-w-moore]

@alanking sounds right. The PRC can expose the new timestamp attributes conditionally , based on an optional- or lazy-load policy , informed by whether our new specific query for those timestamps is loaded or not. (as opposed to making the query undeletable, which I'm guessing is not feasible.)

[alanking]

Okay. I'm going to mark this as an enhancement, but I'm willing to be convinced that it's something else. :)

[korydraughn]

@alanking sounds right. The PRC can expose the new timestamp attributes conditionally , based on an optional- or lazy-load policy , informed by whether our new specific query for those timestamps is loaded or not. (as opposed to making the query undeletable, which I'm guessing is not feasible.)

The decision to provide a SpecificQuery is up to the admin.

The only things for us to do are:

• Expose the columns via GenQuery
• Decide whether the columns get an entry in library_features.h
• Update the PRC to conditionally include the columns if the iRODS zone supports them

@alanking Agreed. Marking as enhancement is good.

[paulborgermans]

Thanks for this, until it lands in a release, I will use a specific query