Bug #2749

During initialization from deserialization (lazy loading), results that need to fill their parameters from their parent can't if the parent is not ready

Added by Sebastien Jacquot about 1 year ago. Updated 8 months ago.

Status:New Start date:01/29/2020
Priority:High Due date:
Assignee:- % Done:


Category:Persistence / Lazy Spent time: -
Target version:TXM 0.8.2


Related to the issues fixed in 0.8.1, see #2682.

During initialization from deserialization (reloading), results that need to fill their parameters from their parent can't if the parent is not ready.
When creating a result, it tries to load its parameters from preference nodes and from manual implementations of the TXMResult.loadParameters() method.
It may leads to the fail of loading some parameters if the parent is not ready.

E.g. A partition tries to get its property object from its parent corpus but fails if the corpus is not ready (in CQP).
See org.txm.searchengine.cqp.corpus.Partition.loadParameters():

 try {
            tmp = this.getStringParameterValue(TBXPreferences.STRUCTURAL_UNIT_PROPERTY);
            if (!tmp.isEmpty()) {
                this.pProperty = StructuralUnitProperty.stringToStructuralUnitProperty(this.getParent(), tmp);

At this time, it doesn't break the lazy reloading because the partition is recreated from its queries and not using its possibly existing structural unit property.


  • previous issues about parents branch ready states have been resolved in the UI layer, see #2682
  • I think CQP Corpus objects have a special status. They need to be ready in CQP in a lot of contexts.
    => as a temporary or definitive solution, I propose to force their computing at project opening.
  • computing a CQP corpus is not a long process
  • computing a partition can be a very long process
    => computing them at start will break the lazy lodaing


  • identify which results try to get some parameters from their parents in TXMResult.loadParameters()
  • define the loss in lazy terms of forcing the computing of CQPCorpus object at RCP Projects opening
    => force or not the computing
  • define what to do with Partition object
    => e.g., what happens if a result needs to load some parameters of its partition parent?
  • as we already discuss about it, the compute() method of Corpus is more a loading in CQP than a build/compute, we may move the code to a load() method called in the CQPCorpus constructor

This issue is also related to the messages that must be shown in Log or UI when they are based on some parent parameters or data values.

Solutions for the CQPCorpus object

  • force CQPCorpus objects computing at project opening or TXM launch
  • force CQPCorpus objects computing in existing utilities methods as StructuralUnitProperty.stringToStructuralUnitProperty(), etc.
  • force CQPCorpus objects computing in themselves methods as CQPCorpus.getStructuralUnit(String name)

General solutions

  • protect all TXMResult getters methods with a this.compute(false)
    => may be automatized using Java Annotation, e.g. @needCompute that would call a compute if needed
    => problem here is it can lead to call long processes at indeterminate moments


Call result.getParent().compute(false) in various key moments:
  • when opening a TXMResult editor : most of results editors
  • when opening Parameter dialog : Partition, Subcorpus, corpus export


#1 Updated by Sebastien Jacquot about 1 year ago

  • Description updated (diff)

#2 Updated by Sebastien Jacquot about 1 year ago

  • Description updated (diff)

#3 Updated by Matthieu Decorde about 1 year ago

  • Description updated (diff)
  • % Done changed from 0 to 80

#4 Updated by Sebastien Jacquot about 1 year ago

  • Target version changed from TXM 0.8.1 to TXM 0.8.2
  • % Done changed from 80 to 0

#5 Updated by Matthieu Decorde 8 months ago

  • Priority changed from Normal to High

Also available in: Atom PDF