Lucene - Core
  1. Lucene - Core
  2. LUCENE-4001

Grouping module shouldn't depend on queries module

    Details

    • Type: Task Task
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Lucene Fields:
      New

      Description

      Spin off from LUCENE-3997. Basically move FunctionValues and ValueSource to core.

        Activity

        Hide
        Martijn van Groningen added a comment -

        It turns out that three files need to be moved:

        svn mv lucene/queries/src/java/org/apache/lucene/queries/function/FunctionValues.java lucene/core/src/java/org/apache/lucene/search/
        svn mv lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java lucene/core/src/java/org/apache/lucene/search/
        svn mv lucene/queries/src/java/org/apache/lucene/queries/function/ValueSourceScorer.java lucene/core/src/java/org/apache/lucene/search/
        
        Show
        Martijn van Groningen added a comment - It turns out that three files need to be moved: svn mv lucene/queries/src/java/org/apache/lucene/queries/function/FunctionValues.java lucene/core/src/java/org/apache/lucene/search/ svn mv lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java lucene/core/src/java/org/apache/lucene/search/ svn mv lucene/queries/src/java/org/apache/lucene/queries/function/ValueSourceScorer.java lucene/core/src/java/org/apache/lucene/search/
        Hide
        Chris Male added a comment -

        I have real reservations about doing this. In LUCENE-3997 I explained that I feel we should only move classes into core if they are part of core APIs / concepts. I don't think FunctionValues and ValueSource are in that boat. To me they seem tightly bound to FunctionQuery and the implementations in the queries module. Yes the grouping module uses them, but that doesn't immediately make them core. I also feel that in 99% of cases, people who want to group by function will be using the impls in the queries module, so why remove the dependency?

        Show
        Chris Male added a comment - I have real reservations about doing this. In LUCENE-3997 I explained that I feel we should only move classes into core if they are part of core APIs / concepts. I don't think FunctionValues and ValueSource are in that boat. To me they seem tightly bound to FunctionQuery and the implementations in the queries module. Yes the grouping module uses them, but that doesn't immediately make them core. I also feel that in 99% of cases, people who want to group by function will be using the impls in the queries module, so why remove the dependency?
        Hide
        Martijn van Groningen added a comment -

        In think that there are other features that might want to use functions. Faceting by function or joining by function seem like things that could be added in the future. Question is does this make functions a core concept? After some thinking it seems to me that functions are not a core concept.

        What I think is a core concept is the abstraction of a where a values comes from (output of a function, int from FC or double from doc values). Perhaps this concept should be in core. The grouping module can use this concept instead of the function concept. This way the grouping module doesn't need to depend on the queries module. MutableValue is already in core, which is good. I think for this to happen we need to change FunctionValues.ValueFiller into MutableValueSource that has the following method:

        public interface MutableValueSource {
        
           public MutableValue getValue(int doc, MutableValue reuse){
              ...
           }
        
        }
        

        This also looks similar to how we use FieldCache or DocValues.Source.

        Show
        Martijn van Groningen added a comment - In think that there are other features that might want to use functions. Faceting by function or joining by function seem like things that could be added in the future. Question is does this make functions a core concept? After some thinking it seems to me that functions are not a core concept. What I think is a core concept is the abstraction of a where a values comes from (output of a function, int from FC or double from doc values). Perhaps this concept should be in core. The grouping module can use this concept instead of the function concept. This way the grouping module doesn't need to depend on the queries module. MutableValue is already in core, which is good. I think for this to happen we need to change FunctionValues.ValueFiller into MutableValueSource that has the following method: public interface MutableValueSource { public MutableValue getValue( int doc, MutableValue reuse){ ... } } This also looks similar to how we use FieldCache or DocValues.Source.

          People

          • Assignee:
            Unassigned
            Reporter:
            Martijn van Groningen
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development