EPrints Technical Mailing List Archive

See the EPrints wiki for instructions on how to join this mailing list and related information.

Message: #02846

< Previous (by date) | Next (by date) > | < Previous (in thread) | Next (in thread) > | Messages - Most Recent First | Threads - Most Recent First

[EP-tech] Thousands of old eprints repropagated via OAI after epadmin redo_thumbnails &co.

Hi,
is there an option (am I just missing it? using EPrints v3.3.10) to leave the current lastmod timestamp untouched when processing an epadmin or alike routine automated by EPrints-boxed tools? We had in the past and will still have a need to batch-process plenty of eprints, epadmin redo_thumbnails for instance, which results in e.g. their being renotified via our aggregator for freshly acquired media (RSS-feed and mail channel both are limited to 1000 items per request, thus some really fresh ones might be suppressed in the list). Client OAI harvesters might handle them as new, too, which would be not that user-friendly.
Pondering on it, I would even prefer to see EPrints update it only when a non-admin user has acted upon an eprint, when they changed metadata. But sometimes the admin might want to touch eprints "obviously" indeed, e.g. when he changed field values using the regular workflow or when he explicitly opts in that. 

To put it in a nutshell, I'd wish I could use EPrints API this way:

   use EPrints qw(no_autoupdate_lastmod);

   $dataobj->commit(); # stealth update if $dataobj in storage
   $dataobj->commit({ update_lastmod => 1 });
       # opt-in overwrite default {update_lastmod}
       #     = !exists $import_opts{no_autoupdate_lastmod}
In order to ensure that changes made by admin are still obvious in terms of database-level debugging or "forensics", my idea is to have an API-hidden and unprocessed native DATESTAMP field, say "sql_updated", and have it independently update with means of the database engine. (AFAIK, MySQL implies out-of-the-box "ON UPDATE CURRENT_TIMESTAMP()" for any first datestamp field of a table.)
By the way, guessing there isn't another way to restore the timestamps but from backup dumps, is there? Is there yet a way to commit an eprint explicitly without updating the lastmod timestamp that I can consider in the future to prevent this? 


Regards
Florian

--
UB Heidelberg (Altstadt)
Plöck 107-109, 69117 HD
Abt. Informationstechnik
http://www.ub.uni-heidelberg.de/