EPrints Technical Mailing List Archive

Message: #02883

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

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

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/