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

Florian Heß hess at ub.uni-heidelberg.de
Mon Apr 14 12:50:21 BST 2014

Am 09.04.2014 18:46, schrieb Sebastien Francois:
> Fair point!...
> So when someone runs epadmin recommit, the script forces the recommit
> ($dataobj->commit( 1 )) which *always* writes data to the database,
> regardless of whether the data-obj was modified during the re-commit.
> So if I understand correctly your case-studies, it seems like you need:
> 1- epadmin recommit
> 2- epadmin force-recommit
> v1 could do $dataobj->commit() -> no change in the dataobj = no DB
> write, no update of lastmod, revision, history. Change in the dataobj =>
> lastmod, revision, history updated

Hi Sebastien

for the sake of backward compatibility I would humbly suggest the other 
way round instead: recommit => commit(1) and lazy-recommit => commit(0).

> But for other cases, if the metadata is updated then lastmod must be
> updated. And the OAI protocol is consistent with this behaviour:
> [...]
> So what you cannot have (if you want to respect OAI) is updating some
> item's metadata and not update the lastmod field (you can of course find
> ways to achieve this result but not OAI-friendly).

Yes, stealth update would have been just a nice-to-have feature, nothing 
of evident need. Internal information that a script might put into 
suggestions field (a general purpose field for information addressed at 
staff only), eg. "record transferred to system foo in bucket bar at 
yymmdd hh:mm:ss" does not quite need to update lastmod in my eyes, but 
public vs. non-public destinction in respect to whether or not lastmod 
is touched could yet be another sharp edge that novice' understanding of 
over-all EPrints system might snag on.

> So... given the conversations we've had so far - would the suggested
> changes (the "don't touch lastmod if no metadata change has occurred")
> be compatible with what you're trying to achieve?
Absolutely, thank you very much ...


> Thanks for keeping the conversation up. Once we're both happy, let's
> propagate this to github.

> Seb.
> *** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
> *** Archive: http://www.eprints.org/tech.php/
> *** EPrints community wiki: http://wiki.eprints.org/
> *** EPrints developers Forum: http://forum.eprints.org/

UB Heidelberg (Altstadt)
Plöck 107-109, 69117 HD
Abt. Informationstechnik
Tel. 06221 / 54 3550

More information about the Eprints-tech mailing list