<div dir="ltr">I think that negative queries could be added, just like I added multi-queries in WINDUP-133: <a href="https://github.com/lincolnthree/windup/blob/WINDUP-133/config/api/src/main/java/org/jboss/windup/config/query/QueryPropertyCriterion.java#L33">https://github.com/lincolnthree/windup/blob/WINDUP-133/config/api/src/main/java/org/jboss/windup/config/query/QueryPropertyCriterion.java#L33</a></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 7, 2014 at 2:47 PM, Jess Sightler <span dir="ltr"><<a href="mailto:jsightle@redhat.com" target="_blank">jsightle@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br>
On 07/31/2014 04:29 PM, Ondrej Zizka wrote:<br>
> When talking to Robb, we discussed the ability to query for POJO classes<br>
> - i.e. those which do not have any vendor-specific extension, do not use<br>
> blacklisted classes, do not extend something "dirty", etc.<br>
><br>
> Which brings us to interesting concept - querying for something "not<br>
> being a lot of things".<br>
><br>
> We have discussed this briefly on F2F with Brad.<br>
> The first shot could be:<br>
><br>
> * creating a method which will query for vertexes that have some frame<br>
> type (JavaClass), but not any other, or a set of other types<br>
> (WebLogicContextListener).<br>
<br>
</div>One issue here is that the Titan Text predicate does not directly<br>
support negations. I am not sure how easy it would be to add this in a<br>
performant manner for a negated type search.<br>
<br>
I agree that this is a need, though for certain types of queries.<br>
<div class=""><br>
><br>
> * querying for vertices which are not linked to vertices in sevral<br>
> blacklists<br>
> For example, querying for JavaClass'es not linked to a list of<br>
> other JavaClass'es by an "extends" edge.<br>
> This will need some way to keep the blacklists in the graph, and<br>
> then, I can imagine Gremlin taking the part in filtering out the<br>
> vertices linked to them by a set of edge types ("extends", "implements",<br>
> "annotatedBy", "calls", "imports", ...)<br>
><br>
> And creating a disjunction of all these results, by narrowing the set of<br>
> candidate vertices, step by step.<br>
<br>
</div>I think that things like require gremlin queries. It would be logical<br>
for us to build some building blocks for complex queries like this so<br>
that users don't have to fully understand gremlin (and the rather<br>
complex graph structure) for more common operations. For an example, see<br>
the FindClassifiedFilesGremlinCriterion class.<br>
<div class=""><br>
> What I think is a BAD approach, is this kind of rules (outside of Java<br>
> basic analysis):<br>
><br>
> Query.find(JavaClassModel.class).as("javaClasses")<br>
><br>
> Iteration.over("javaClasses").as("javaClass").perform(<br>
> ...<br>
> )<br>
><br>
><br>
<br>
</div>I don't think that anyone has advocated for that type of approach,<br>
outside of the cases where you actually want to iterate over all of the<br>
JavaClassModels in the graph.<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
windup-dev mailing list<br>
<a href="mailto:windup-dev@lists.jboss.org">windup-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/windup-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/windup-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Lincoln Baxter, III<br><a href="http://ocpsoft.org" target="_blank">http://ocpsoft.org</a><br>"Simpler is better."
</div>