on article delete, remove relevant cache keys and and remove article from any collections (journal or issue) it belongs to

Hm. I'm surprised. Anyway, I know I've missed a few things on virtual journals.

The article delete code (source:head/plosone/libs/article-util/src/main/java/org/plos/article/util/ArticleUtil.java) uses otm, fedora and fedoragsearch (lucene) to delete the article. I'm not sure what else is necessary for virtual journals.

Replying to ebrown:

Hm. I'm surprised. Anyway, I know I've missed a few things on virtual journals. The article delete code (source:head/plosone/libs/article-util/src/main/java/org/plos/article/util/ArticleUtil.java) uses otm, fedora and fedoragsearch (lucene) to delete the article. I'm not sure what else is necessary for virtual journals.

The article-uri is sitting in the simpleCollection for the CT journal. So a simple criteria or OQL on Aggregation with simpleCollection = <aritcle-doi> and then delete the article-doi from the list and save the Aggregation back.

These sort of things is why I'm more and more convinced we should not be attempting to have scripts go muck with things, but instead should be providing url's (REST) for the operations (you can still write a script, but it should just be sending a request to the url). That also ensures that the running system gets updated and doesn't need to be restarted after every such operation.

Replying to ronald:

These sort of things is why I'm more and more convinced we should not be attempting to have scripts go muck with things, but instead should be providing url's (REST) for the operations (you can still write a script, but it should just be sending a request to the url). That also ensures that the running system gets updated and doesn't need to be restarted after every such operation.

I agree. Problem has been getting the time to do the REST interface. This will have to be fixed for short term.

Milestone 0.9 deleted

while you're at it (should this ever happen :) the script should also invalidate the article cache and browse caches for relevant journals so that delete doesn't require a restart...

Replying to russ:

while you're at it (should this ever happen :) the script should also invalidate the article cache and browse caches for relevant journals so that delete doesn't require a restart...

This already happens on internal deletes. I.e. as soon as the script gets removed or reduced to a 5-line shell that talks to plosone this will work as expected.

reassigning to alex since he's added an article delete action to the admin interface which should clear browse cache and remove from collections as well.

i'm not sure what the prognosis is for this with the article_delete script. it's nice to have the ability to delete multiple articles at once, which the script provides and the admin interface action does not. but if it's going to be hard to get the script to play nice, then we can probably decide not to improve it.

caches/keys that need clearing on article delete:

* ArticleAnnotationCache?

• 3 keys

* BrowseCache?

• Article-info key
• DateList? for the relevant journal
• ArtByCat? for the relevant journal
• ArtByDate? for the relevant journals and date ranges (or just clear all ArtByDate? for the relevant journal)

* SimplePageCachingFilter?

• Currently impossible to delete a single key, and not worth the pain of clearing the whole cache. See #278.

* article-state

• Perhaps the other XACML caches too?

(In [5657]) Remove SimplePageCachingFilter? and its associated cache.

The object-cache now holds the blobs that this filter was caching. Moreover the object-cache is journal context aware and will be invalidated when article is deleted/re-ingested as well as when the journal membership changes.

This closes #740,#278 and addresses #610,#901.

Duplicate of #901. This should be fixed now.