[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 ...
Florian
> 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
http://www.ub.uni-heidelberg.de/
More information about the Eprints-tech
mailing list