Ticket #992 (closed defect: fixed)

Opened 4 months ago

Last modified 3 months ago

representationCache keys are not cleared correctly on reingest (perhaps old reps persist in mulgara as well?)

Reported by: russ Assigned to: pradeep
Priority: high Milestone: 0.9.0
Component: ambra Version: 0.9-rc1
Keywords: Cc:
Blocking: Blocked By:

Description

after an article delete through the admin pages, the keys in RepresentationCache? for the deleted objects are evicted.

however, if you reingest using the "force ingest" checkbox, the keys are not deleted.

pradeep suspects that the old representations are, in fact, being left behind in mulgara.

it's still unclear if this is a functional problem, or just a case of leftover data that isn't harming anyone, but should still be deleted, but we have some reports of article XML failing to update on reingest that could be related.

Dependency Graph

Change History

07/21/08 12:06:36 changed by russ

after updating the pdf and reingesting pone.0001780 on dev, the following two keys were in RepresentationCache?:

{{{RepresentationCache?.get(info:doi/10.1371/representation/7142a107-ec08-42 79-bcb0-85f166fac90f) = types = http://rdf.topazproject.org/RDF/Representation, values = {Representation:contentType=[application/pdf], Representation:object=[info:doi/10.1371/journal.pone.0001022], Representation:name=[PDF], Representation:size=[86846], Representation:lastModified=[2008-07-21T18:04:30.776Z]} }}} 

RepresentationCache.get(info:doi/10.1371/representation/d9051d47-a1ac-42
87-8e65-3960077cce37) = types =
[http://rdf.topazproject.org/RDF/Representation], values = {Representation:contentType=[application/pdf],
Representation:object=[info:doi/10.1371/journal.pone.0001022],
Representation:name=[PDF], Representation:size=[285310], Representation:lastModified=[2008-07-21T17:58:31.551Z]}

07/21/08 15:17:47 changed by rich

  • priority changed from unassigned to medium.

07/23/08 12:33:10 changed by ronald

  • owner changed from pradeep to ronald.
  • status changed from new to assigned.

08/06/08 00:41:56 changed by ronald

(In [6306]) Use session.merge() instead of saveOrUpdate() if the article already exists. This addresses #992.

(follow-up: ↓ 7 ) 08/06/08 00:58:13 changed by ronald

  • owner changed from ronald to pradeep.
  • status changed from assigned to new.

The merge() is still not removing old stuff (e.g. Representations), i.e. this ticket can't be closed until merge() is fixed.

08/06/08 01:03:54 changed by amit

  • priority changed from medium to high.

(in reply to: ↑ 5 ) 08/06/08 08:39:38 changed by pradeep

  • owner changed from pradeep to ronald.

Replying to ronald:

The merge() is still not removing old stuff (e.g. Representations), i.e. this ticket can't be closed until merge() is fixed.

The Article content model needs to be looked at and the associations that must disappear when an Article is deleted must be marked as cascading orphan-deletes.

Because that is essentially what is happening. 'delete' cascades by default. But not orphan delete. ie. when a Representation is replaced, the old one is an orphan and would not delete it. Only the association will be deleted.

08/13/08 13:43:12 changed by amit

  • owner changed from ronald to pradeep.

08/16/08 01:06:09 changed by ronald

  • status changed from new to closed.
  • resolution set to fixed.

(In [6344]) Fix merge() when the old entity had lazy-loaded collections by forcing them to be loaded in the copy() before the sync(). This closes #992.