OCL Interactive Query fails for large file [message #693995] |
Thu, 07 July 2011 15:42 |
|
I have a model with the following structure
DocumentRoot
MultiBlock
Block
BlockDef
EmbBlocks
Block
BlockDef
Block
BlockDef
Block
BlockDef
Block
BlockDef
EmbBlocks
Block
BlockDef
Block
BlockDef
Block
BlockDef
The metamodel relationships are that
DocumentRoot may contain a MultiBlock
MultiBlock may contain many Block
Block may contain a BlockDef
Block may contain a EmbBlocks
EmbBlocks may contain many Block
I have attached the metamodel, generated editor and a sample XML file.
I use this editor to open the sample XML file.
I then show the an OCL Interactive console
from the context of MultiBlock, I run the following query
Evaluating:
block.embBlocks.block.blockDef
Results:
Block Def 02_AI_3014
Block Def 02_AI_3166
Block Def 02_AN_3100
Block Def 02_AN_4100
Block Def 02_FE_1150A
Block Def 02_FE_1150B
Block Def 02_FI_1012
Block Def 02_FI_1014
Block Def 02_FI_3120
Block Def 02_FI_3120_COND
Block Def 02_FIC_1210
Block Def 02_FIC_1210_COND
Block Def 02_FIC_1400
Block Def 02_FIC_1400_COND
Block Def 02_FIC_1750A
Block Def 02_FN_1014
Block Def 02_FQI_1014
Block Def 02_PDIC_4018
Block Def 02_PI_1014
Block Def 02_TI_1014
Block Def V_2XX_SEQ
Block Def V_2XX_STATUS
However when I run the following query on a large file that has about 4000 blocks, it fails with the following message:
Evaluating:
block.embBlocks.block.blockDef
Results:
Evaluation failure
'Collection' value required
Do you know why this is happening and how I can fix it?
-Mark
|
|
|
|
|
Re: OCL Interactive Query fails for large file [message #694188 is a reply to message #694078] |
Fri, 08 July 2011 04:02 |
|
Ok I figured it out.
Because EmbBlock objects are optional, I have to first check to see if a block exists, then I can navigate down it.
Here is the query I used:
block->select(embBlocks->notEmpty()).embBlocks.block.blockDef.blockName
Ed, is there a slicker way to navigate down an association without first checking to see if it exists (in cases of multiplicity 0..*)?
-Mark
|
|
|
Re: OCL Interactive Query fails for large file [message #694233 is a reply to message #694188] |
Fri, 08 July 2011 07:03 |
Ed Willink Messages: 7655 Registered: July 2009 |
Senior Member |
|
|
Hi Mark
Removing the implicit collect which can often add confusion, you have
found that
a->collect(b)-> ...
has limitations that are worked around by
a->select(b->notEmpty())->collect(b)->...
which would suggest a fault in the specification or implementation of
collect(). The specification seems ok, and the implementation seems ok
on my tests; I was unable to get your example to load, so I suspect that
you have misdiagnosed your problem.
Using Ecore.ecore as a test vehicle, select EObject, then
Evaluating:
eOperations.eParameters.eType.name
Results:
'EStructuralFeature'
'EStructuralFeature'
'EBoolean'
'EStructuralFeature'
'EJavaObject'
'EStructuralFeature'
'EStructuralFeature'
'EOperation'
'EEList'
demonstrates successful pruning of many argument-less operations.
I think your problem is shown by
Evaluating:
eOperations.eType.name
Results:
OclInvalid
which is because
Evaluating:
eOperations.eType
Results:
EClass -> EClassifier
EBoolean [boolean]
EResource [org.eclipse.emf.ecore.resource.Resource]
EObject
EStructuralFeature -> ETypedElement
EReference -> EStructuralFeature
EEList<E> [org.eclipse.emf.common.util.EList]
ETreeIterator<E> [org.eclipse.emf.common.util.TreeIterator]
EEList<E> [org.eclipse.emf.common.util.EList]
EJavaObject [java.lang.Object]
EJavaObject [java.lang.Object]
null
EBoolean [boolean]
null
EJavaObject [java.lang.Object]
has two null values for optional [0..1] multiplicity elements.
This can be fixed by
Evaluating:
eOperations.eType->excluding(null).name
Results:
'EClass'
'EBoolean'
'EResource'
'EObject'
'EStructuralFeature'
'EReference'
'EEList'
'ETreeIterator'
'EEList'
'EJavaObject'
'EJavaObject'
'EBoolean'
'EJavaObject'
Explicitly that was
eOperations->collect(eType)->excluding(null)->collect(name)
which isn't that unreasonable, so long as [0..1] is not a collection.
Just use ->excluding(null) to get rid of nulls before you try to
navigate them.
Regards
Ed Willink
On 08/07/2011 05:02, Mark Sluser wrote:
> Ok I figured it out. :d
> Because EmbBlock objects are optional, I have to first check to see if
> a block exists, then I can navigate down it.
>
> Here is the query I used:
>
>
> block->select(embBlocks->notEmpty()).embBlocks.block.blockDef.blockName
>
>
>
> Ed, is there a slicker way to navigate down an association without
> first checking to see if it exists (in cases of multiplicity 0..*)?
>
> -Mark
>
>
>
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03991 seconds