Home » Modeling » OCL » When must Query objects be reconstructed?
| When must Query objects be reconstructed? [message #64590] |
Thu, 13 November 2008 20:43  |
Eclipse User |
|
|
|
Hello,
I am working with code that is currently caching org.eclipse.ocl.Query
objects. However, I noticed a problem recently where the LazyExtentMap
incorrectly caches the instances of a particular EClass causing
subsequent executions of the query to sometimes produce incorrect
results. The OCL expression is using the "allInstances()" operation.
So, I was just wondering how long is it safe to cache the Query? Can a
Query be reused at all? I'm assuming that it can only be used for other
objects of the same type (EClass) that are in the same root. If a Query
object can be reused at all, can it be used if the underlying roots (or
their contents) have changed or should it be thrown away in that case?
Thanks,
Chris McGee
|
|
|
| Re: When must Query objects be reconstructed? [message #64613 is a reply to message #64590] |
Thu, 13 November 2008 21:39  |
| Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Chris,
See some replies in-line, below.
HTH,
Christian
Chris McGee wrote:
> Hello,
>
> I am working with code that is currently caching org.eclipse.ocl.Query
> objects. However, I noticed a problem recently where the LazyExtentMap
> incorrectly caches the instances of a particular EClass causing
> subsequent executions of the query to sometimes produce incorrect
> results. The OCL expression is using the "allInstances()" operation.
Well, it isn't actually the LazyExtentMap that is incorrectly caching
the EClass extents, but rather the object that is caching the Query.
Which, judging by your post's subject, is what you suspect already ;-)
> So, I was just wondering how long is it safe to cache the Query? Can a
The query can be cached as long as you know that the EClass extents in
your resource (or whatever scope) won't change. Generally, this is as
long as there is some assurance of the model not changing (e.g., a
transaction in an EMF Transaction context, a validation operation in EMF
Validation, etc.)
> Query be reused at all? I'm assuming that it can only be used for other
Yes. The idea is that they might be re-used in a sequence of
evaluations of the same expression over a bunch of objects, where the
model is static for the duration.
> objects of the same type (EClass) that are in the same root. If a Query
Right, the Query is stuck in whatever the scope of its EClass extent is
(Resource or ResourceSet, usually).
> object can be reused at all, can it be used if the underlying roots (or
> their contents) have changed or should it be thrown away in that case?
Right, it would need to be tossed when any changes occur, unless perhaps
you know that EObjects haven't been added or removed by those changes.
I have seen applications that will cache Query instances in the UML
CacheAdapter, for example, which purges itself ony (almost) any change. :-)
> Thanks,
> Chris McGee
|
|
|
| Re: When must Query objects be reconstructed? [message #64636 is a reply to message #64613] |
Fri, 14 November 2008 09:16 |
| Eclipse User |
|
|
|
Thanks for your help Christian.
Yes, sorry. I guess what I meant was that the caching of instances in
the LazyExtentMap was not good for my use case where the model is
changing in between invocations of the query. :-) LazyExtentMap is
correct in keeping such a cache as it could be expensive calculation for
large resources or resource sets.
Chris
Christian W. Damus wrote:
> Hi, Chris,
>
> See some replies in-line, below.
>
> HTH,
>
> Christian
>
>
> Chris McGee wrote:
>> Hello,
>>
>> I am working with code that is currently caching org.eclipse.ocl.Query
>> objects. However, I noticed a problem recently where the LazyExtentMap
>> incorrectly caches the instances of a particular EClass causing
>> subsequent executions of the query to sometimes produce incorrect
>> results. The OCL expression is using the "allInstances()" operation.
>
> Well, it isn't actually the LazyExtentMap that is incorrectly caching
> the EClass extents, but rather the object that is caching the Query.
> Which, judging by your post's subject, is what you suspect already ;-)
>
>
>> So, I was just wondering how long is it safe to cache the Query? Can a
>
> The query can be cached as long as you know that the EClass extents in
> your resource (or whatever scope) won't change. Generally, this is as
> long as there is some assurance of the model not changing (e.g., a
> transaction in an EMF Transaction context, a validation operation in EMF
> Validation, etc.)
>
>
>> Query be reused at all? I'm assuming that it can only be used for other
>
> Yes. The idea is that they might be re-used in a sequence of
> evaluations of the same expression over a bunch of objects, where the
> model is static for the duration.
>
>
>> objects of the same type (EClass) that are in the same root. If a Query
>
> Right, the Query is stuck in whatever the scope of its EClass extent is
> (Resource or ResourceSet, usually).
>
>
>> object can be reused at all, can it be used if the underlying roots
>> (or their contents) have changed or should it be thrown away in that
>> case?
>
> Right, it would need to be tossed when any changes occur, unless perhaps
> you know that EObjects haven't been added or removed by those changes. I
> have seen applications that will cache Query instances in the UML
> CacheAdapter, for example, which purges itself ony (almost) any change.
> :-)
>
>
>> Thanks,
>> Chris McGee
|
|
|
| Re: When must Query objects be reconstructed? [message #64659 is a reply to message #64636] |
Fri, 14 November 2008 09:57 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Chris,
No problem! I'm glad to help, and quite understood your meaning. I
just tend to be verbose ...
cW
Chris McGee wrote:
> Thanks for your help Christian.
>
> Yes, sorry. I guess what I meant was that the caching of instances in
> the LazyExtentMap was not good for my use case where the model is
> changing in between invocations of the query. :-) LazyExtentMap is
> correct in keeping such a cache as it could be expensive calculation for
> large resources or resource sets.
>
> Chris
>
-----8<-----
|
|
|
Goto Forum:
Current Time: Fri Oct 31 00:30:24 EDT 2025
Powered by FUDForum. Page generated in 0.04549 seconds |
Home