[windup-dev] Negative queries?

[Lincoln Baxter, III]

No, definitely won't ;)


On Thu, Aug 7, 2014 at 3:05 PM, Jess Sightler <jsightle at redhat.com> wrote:

>  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> 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
>> https://lists.jboss.org/mailman/listinfo/windup-dev
>>
>
>
>
>  --
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."
>
>
> _______________________________________________
> windup-dev mailing listwindup-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/windup-dev
>
>
>
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
>



-- 
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140808/c3f92377/attachment-0001.html