Re: [cme-users] Query Language NOT operator

[Peri Tarr <tarr@xxxxxxxxxx>]

Hi Juri,

Well, I probed further, and your workaround
is actually much easier and requires no patches (and the fundamental problem
with the parser is much worse to work around).  Use "in"
instead of "within", and your query should work (at least, it
does not produce syntax errors--I don't have your code base, so I can't
tell):

call( * Cosmos.execute(..)) &&
in(sourceof(relationship extends(class * ,class Concern)))

     Peri

Peri Tarr/Watson/IBM@IBMUS
Sent by: cme-users-admin@xxxxxxxxxxx

07/28/2004 01:30 PM

Please respond to
cme-users

To	CME Users <cme-users@xxxxxxxxxxx>
cc
Subject	Re: [cme-users] Query Language NOT operator

Hi Juri, 

Sorry for not responding sooner--for some reason, this message missed me
(or perhaps I accidentally deleted it during a mass killing of reams of
spam :-)), so Harold just brought it to my attention.

  >I just stumbled about a small problem that I do not seem to
be able to
 >handle.
 > 
  >I would like to express:
 > 
  >All calls to the method execute in the class Cosmos that are
only from
 >within a class that extends Concern. 

Let me be sure I'm clear on this:  you want all calls to Cosmos.execute(..)
such that the calls occur in subclasses of class Concern?  (I'm going
to assume this is what you mean subsequently, but if I'm wrong, probably
everything else I tell you is wrong :-), so let me know what you actually
meant.)

  >I can do
 >[1] "call( * Cosmos.execute(..))"
 >and get all the calls.
 > 
  >I can also do
 >[2] "relationship extends(class * ,class Concern)"
 >and get all the classes
 > 
  >Now, I want to combine both and that does not work out in any
form.
 > 
  >The best I could come up with was:
 > 
  >[3] "call( * Cosmos.execute(..)) && within(sourceof(relationship
 >extends(class * ,class Concern)))"
 > 
  >Unfortunately, this gives me a syntax error ("Syntax Error
in query.
 >Reason: Syntax Error in query") which is less than enlightening
to me. 

Interesting.  That's the query I would have suggested.

Okay, I've looked into this, and it's a problem with our query parser--it's
treating "within" as an identifier instead of as a reserved word.
 (This traces back to a problem with our parser generator, which I'm
in the process of replacing.)  Would you do me a favor and raise it
as a bug, please?  I'll do the interim fix, which is to disallow the
use of AspectJ pointcut tokens as identifiers, and then probably will be
able to address this issue properly when I've finished the move to the
new parser generator.  (Sorry, this problem probably arose as the
result of a fix to a different problem in the parser generator; I'm really
surprised that the test suite didn't pick it up, because we have test cases
for it, but I'll update those as well, so this was a particularly good
catch--thanks.)

  >I assume that, beyond the syntax error, I also have a scope
problem,
 >searching for methods in the first part and classes in the second...
but
 >there is more... 

No, I think you're fine here.

  >After reading the sample queries again, I realized that I could
do the
 >same with a variation of
 > 
  >"sourceof(relationship invokes(method * foo(..), in(concern
C1))"
 > 
  >I would have to replace the "in..." part with something
similar to [2].
 >But no success with that one, either. :-(

Fortunately, it's the same problem as for "within".  Same
fix will address it.

  >Now, once I have (somehow) done that, I also want to change
the logical
 >and to a logical not to find those elements that I filtered out before.

Should work fine once the parse problem is addressed.  (Do you know,
incidentally, that you can use ! or -, where - lets you remove one set
of elements from another (e.g., A-B will give you the set of things that
are in A but not in B)?  It's quite often MUCH cleaner (and faster)
than using !, so I wanted to be sure to point it out to you.

  >I am certain that this is not really complicated, but I don't
seem to
 >get this running.

Sorry it caused you problems, but fortunately, I think it's a 5-minute
workaround, so I may even have you running today :-).  Thanks for
raising the issue! 

     Peri