I don't think that will be faster than just returning all of the elements and manually filtering in code, though. A positive search will hit the lucene index and is generally much faster.

On 08/07/2014 02:52 PM, Lincoln Baxter, III wrote:
I think that negative queries could be added, just like I added multi-queries in WINDUP-133: https://github.com/lincolnthree/windup/blob/WINDUP-133/config/api/src/main/java/org/jboss/windup/config/query/QueryPropertyCriterion.java#L33


On Thu, Aug 7, 2014 at 2:47 PM, Jess Sightler <jsightle@redhat.com> wrote:

On 07/31/2014 04:29 PM, Ondrej Zizka wrote:
> When talking to Robb, we discussed the ability to query for POJO classes
> - i.e. those which do not have any vendor-specific extension, do not use
> blacklisted classes, do not extend something "dirty", etc.
>
> Which brings us to interesting concept - querying for something "not
> being a lot of things".
>
> We have discussed this briefly on F2F with Brad.
> The first shot could be:
>
> * creating a method which will query for vertexes that have some frame
> type (JavaClass), but not any other, or a set of other types
> (WebLogicContextListener).

One issue here is that the Titan Text predicate does not directly
support negations. I am not sure how easy it would be to add this in a
performant manner for a negated type search.

I agree that this is a need, though for certain types of queries.

>
> * querying for vertices which are not linked to vertices in sevral
> blacklists
>       For example, querying for JavaClass'es not linked to a list of
> other JavaClass'es by an "extends" edge.
>       This will need some way to keep the blacklists in the graph, and
> then, I can imagine Gremlin taking the part in filtering out the
> vertices linked to them by a set of edge types ("extends", "implements",
> "annotatedBy", "calls", "imports", ...)
>
> And creating a disjunction of all these results, by narrowing the set of
> candidate vertices, step by step.

I think that things like require gremlin queries. It would be logical
for us to build some building blocks for complex queries like this so
that users don't have to fully understand gremlin (and the rather
complex graph structure) for more common operations. For an example, see
the FindClassifiedFilesGremlinCriterion class.

> What I think is a BAD approach, is this kind of rules (outside of Java
> basic analysis):
>
>           Query.find(JavaClassModel.class).as("javaClasses")
>
>           Iteration.over("javaClasses").as("javaClass").perform(
>                   ...
>           )
>
>

I don't think that anyone has advocated for that type of approach,
outside of the cases where you actually want to iterate over all of the
JavaClassModels in the graph.

_______________________________________________
windup-dev mailing list
windup-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/windup-dev



--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."


_______________________________________________
windup-dev mailing list
windup-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/windup-dev