Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » OCL Interactive Query fails for large file(OCL Interactive Query fails on a large file)
OCL Interactive Query fails for large file [message #693995] Thu, 07 July 2011 11:42 Go to next message
Mark Sluser is currently offline Mark Sluser
Messages: 15
Registered: June 2011
Location: Calgary
Junior Member
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 #694006 is a reply to message #693995] Thu, 07 July 2011 12:05 Go to previous messageGo to next message
Mark Sluser is currently offline Mark Sluser
Messages: 15
Registered: June 2011
Location: Calgary
Junior Member
I am suspecting my problem is related to the fact that I have a metamodel where
Block can contain EmbBlocks
EmbBlocks can contain Block

Is this recursive relationship problematic of OCL ?

-Mark
Re: OCL Interactive Query fails for large file [message #694078 is a reply to message #693995] Thu, 07 July 2011 14:20 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4014
Registered: July 2009
Senior Member
Hi Mark

I cannot reproduce your error, but I can see clear problems.

Your large file, presumably generated by some program is not an instance
of your Ecore meta-model.

e.g. Block rather than block elements.

Always validate models with the Sample Ecore Reflective Editor as a good
test on the problems other EMF-based tool s may have.

Regards

Ed Willink


On 07/07/2011 16:42, Mark Sluser wrote:
> 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
>
>
>
>
icon10.gif  Re: OCL Interactive Query fails for large file [message #694188 is a reply to message #694078] Fri, 08 July 2011 00:02 Go to previous messageGo to next message
Mark Sluser is currently offline Mark Sluser
Messages: 15
Registered: June 2011
Location: Calgary
Junior Member
Ok I figured it out. Very Happy

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 03:03 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4014
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
>
>
>
Re: OCL Interactive Query fails for large file [message #694396 is a reply to message #694233] Fri, 08 July 2011 09:20 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4014
Registered: July 2009
Senior Member
Hi Mark
> Just use ->excluding(null) to get rid of nulls before you try to
> navigate them.
A deep issue. I've started a discussion on
http://www.linkedin.com/groupItem?view=&gid=3007822&type=member&item=61138419
as to whether the OCL specification is unhelpful, and raised
https://bugs.eclipse.org/bugs/show_bug.cgi?id=351569 to provide a
warning of the hazard.

Regards

Ed Willink
Re: OCL Interactive Query fails for large file [message #694444 is a reply to message #694396] Fri, 08 July 2011 11:48 Go to previous message
Mark Sluser is currently offline Mark Sluser
Messages: 15
Registered: June 2011
Location: Calgary
Junior Member
All that is much simpler,

My idea was to use

block.embBlocks->select(not oclIsUndefined()).block.blockDef

your suggestion is cleaner.

Thanks again Ed.
Previous Topic:Validating superclass constraints in OCL
Next Topic:Navigating a non-navigable (one way) association
Goto Forum:
  


Current Time: Sat Aug 02 02:41:14 EDT 2014

Powered by FUDForum. Page generated in 0.01889 seconds