Eclipse Community Forums: OCL » OCL Interactive Query fails for large file

Help

Home

Home » Modeling » OCL » OCL Interactive Query fails for large file(OCL Interactive Query fails on a large file)

Show: Today's Messages :: Show Polls :: Message Navigator

OCL Interactive Query fails for large file [message #693995]

Thu, 07 July 2011 15:42

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

Attachment: me.marksluser.hwl.exp.cbXml.zip
(Size: 471.44KB, Downloaded 316 times)
Attachment: Hwl-Exp-cbXML_2011-04-13-Example.xml.zip
(Size: 80.11KB, Downloaded 220 times)

Report message to a moderator

Re: OCL Interactive Query fails for large file [message #694006 is a reply to message #693995]

Thu, 07 July 2011 16:05

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

Report message to a moderator

Re: OCL Interactive Query fails for large file [message #694078 is a reply to message #693995]

Thu, 07 July 2011 18:20

Ed Willink

Messages: 7655
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
>
>
>
>

Report message to a moderator

Re: OCL Interactive Query fails for large file [message #694188 is a reply to message #694078]

Fri, 08 July 2011 04:02

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

Report message to a moderator

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

Report message to a moderator

Re: OCL Interactive Query fails for large file [message #694396 is a reply to message #694233]

Fri, 08 July 2011 13:20

Ed Willink

Messages: 7655
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

Report message to a moderator

Re: OCL Interactive Query fails for large file [message #694444 is a reply to message #694396]

Fri, 08 July 2011 15:48

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.

Report message to a moderator

Previous Topic:	Validating superclass constraints in OCL
Next Topic:	Navigating a non-navigable (one way) association

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Apr 25 04:30:12 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter