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

Florian Heß hess at ub.uni-heidelberg.de
Tue Apr 8 07:43:15 BST 2014


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/



More information about the Eprints-tech mailing list