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

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