Bug #2749

Updated by Matthieu Decorde 8 months ago

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

h3. TODO

* 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.


h3. Solutions
for the CQPCorpus object** 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** h3. 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

h3. Solution

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