Re: [windup-dev] Negative queries?

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/mai... On Thu, Aug 7, 2014 at 2:47 PM, Jess Sightler <jsightle(a)redhat.com&gt; 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/windup-dev > -- Lincoln Baxter, III http://ocpsoft.org "Simpler is better." _______________________________________________ windup-dev mailing listwindup-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/windup-dev _______________________________________________ windup-dev mailing list windup-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/windup-dev