[windup-dev] Negative queries?

[Jess Sightler]

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 at redhat.com 
> <mailto:jsightle at 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 at lists.jboss.org <mailto:windup-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140807/09d78bb7/attachment.html