Solr
  1. Solr
  2. SOLR-3926

solrj should support better way of finding active sorts

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 4.0
    • Fix Version/s: 4.2, 6.0
    • Component/s: clients - java
    • Labels:
      None

      Description

      The Solrj api uses ortogonal concepts for setting/removing and getting sort information. Setting/removing uses a combination of (name,order), while getters return a String "name order":

      public SolrQuery setSortField(String field, ORDER order);
      public SolrQuery addSortField(String field, ORDER order);
      public SolrQuery removeSortField(String field, ORDER order);
      public String[] getSortFields();
      public String getSortField();
      

      If you want to use the current sort information to present a list of active sorts, with the possibility to remove then, you need to manually parse the string(s) returned from getSortFields, to recreate the information required by removeSortField(). Not difficult, but not convenient either

      Therefore this suggestion: Add a new method public Map<String,ORDER> getSortFieldMap(); which returns an ordered map of active sort fields. This will make introspection of the current sort setup much easier.

        public Map<String, ORDER> getSortFieldMap() {
          String[] actualSortFields = getSortFields();
          if (actualSortFields == null || actualSortFields.length == 0)
            return Collections.emptyMap();
      
          Map<String, ORDER> sortFieldMap = new LinkedHashMap<String, ORDER>();
          for (String sortField : actualSortFields) {
            String[] fieldSpec = sortField.trim().split(" ");
            sortFieldMap.put(fieldSpec[0], ORDER.valueOf(fieldSpec[1]));
          }
      
          return Collections.unmodifiableMap(sortFieldMap);
        }
      

      For what it's worth, this is possible client code:

      System.out.println("Active sorts");
      
      Map<String, ORDER> fieldMap = getSortFieldMap(query);
      for (String field : fieldMap.keySet()) {
         System.out.println("- " + field + "; dir=" + fieldMap.get(field));
      }
      
      1. SOLR-3926.patch
        19 kB
        Erick Erickson
      2. SOLR-3926.patch
        19 kB
        Eirik Lygre
      3. SOLR-3926.patch
        11 kB
        Eirik Lygre
      4. SOLR-3926.patch
        11 kB
        Eirik Lygre
      5. SOLR-3926.patch
        3 kB
        Eirik Lygre

        Activity

        Hide
        Eirik Lygre added a comment -

        This is a patch to implement SolrQuery.getSortFieldMap(), a better way to introspect a SolrQuery for sort information. The patch contains javadoc for the method, and a new unit test that verifies the implementation.

        Show
        Eirik Lygre added a comment - This is a patch to implement SolrQuery.getSortFieldMap(), a better way to introspect a SolrQuery for sort information. The patch contains javadoc for the method, and a new unit test that verifies the implementation.
        Hide
        Otis Gospodnetic added a comment - - edited

        +1
        Seems useful and the patch is very small, straight-forward, and clean.

        Show
        Otis Gospodnetic added a comment - - edited +1 Seems useful and the patch is very small, straight-forward, and clean.
        Hide
        Yonik Seeley added a comment -

        Splitting on whitespace isn't likely to work to well with everything we can put in the field list these days (functions, augmenters, etc).
        Why not keep sort information in the client code in symbolic form (i.e. not a serialized string), manipulate it there, and then set to the SolrQuery right before submitting it?

        Show
        Yonik Seeley added a comment - Splitting on whitespace isn't likely to work to well with everything we can put in the field list these days (functions, augmenters, etc). Why not keep sort information in the client code in symbolic form (i.e. not a serialized string), manipulate it there, and then set to the SolrQuery right before submitting it?
        Hide
        Eirik Lygre added a comment - - edited

        So, the patch solves my problem , and I'm not sure what the other use cases really are, so i'll be looking at input from others (Yonik Seeley, Otis Gospodnetic?) in order to understand the requirements. My Solr skills do not extend to functions, augmenters, etc – at least not yet!

        Also, to aid the discussion, this is what we got today:

        • SolrQuery stores the sort field as a comma-separated string of "field direction"
        • SolrQuery.getSortField() returns the full string, e.g. "price asc, date desc, qty desc"
        • SolrQuery.getSortFields() yields [ "price asc", " date desc", " qty desc" ], including extraneous whitespace

        Can you provide a couple of examples of how that would/should work with the api, extending my examples below. Then, I'll see if I feel qualified, and if you guys promise to guide with qa, I'll do my best.

        q.addSortField("price", SolrQuery.ORDER.asc);
        q.addSortField("date", SolrQuery.ORDER.desc);
        q.addSortField("qty", SolrQuery.ORDER.desc);
        q.removeSortField("date", SolrQuery.ORDER.desc);
        
        Show
        Eirik Lygre added a comment - - edited So, the patch solves my problem , and I'm not sure what the other use cases really are, so i'll be looking at input from others ( Yonik Seeley , Otis Gospodnetic ?) in order to understand the requirements. My Solr skills do not extend to functions, augmenters, etc – at least not yet! Also, to aid the discussion, this is what we got today: SolrQuery stores the sort field as a comma-separated string of "field direction" SolrQuery.getSortField() returns the full string, e.g. "price asc, date desc, qty desc" SolrQuery.getSortFields() yields [ "price asc", " date desc", " qty desc" ], including extraneous whitespace Can you provide a couple of examples of how that would/should work with the api, extending my examples below. Then, I'll see if I feel qualified, and if you guys promise to guide with qa, I'll do my best. q.addSortField( "price" , SolrQuery.ORDER.asc); q.addSortField( "date" , SolrQuery.ORDER.desc); q.addSortField( "qty" , SolrQuery.ORDER.desc); q.removeSortField( "date" , SolrQuery.ORDER.desc);
        Hide
        Eirik Lygre added a comment -

        Things that seem simple sometimes are. Sometimes they're not

        First, I've found a bug in the current implementation of removeSortField() (not from my patch, but in the release). It works as follows:

        • addSortField() concatinates the "sort" parameter, using a comma with no whitespace. Four fields would be "a asc,b asc,c asc,d asc"
        • getSortFields() now returns a string array free from whitespace: [ "a asc", "b asc", "c asc", "d asc" ]
        • removeSortField("c", ASC) first creates the partial string to remove, e.g. "c asc", then joins all getSortFields() not equal() the string, yielding [ "a asc", "b asc", "d asc" ]
        • However, removeSortField() uses join with whitespace, creating "a asc, b asc, d asc"
        • getSortFields() now returns [ "a asc", " b asc", " d asc"], with a space at the beginning of the last two elements
        • removeSortField("b", ASC) will now fail, since the partial string "b asc" is not equal() the element " b asc"

        The problem can be shown in this (new) test case:

        public void testSolrQuerySortRemove() {
          SolrQuery q = new SolrQuery("dog");
          q.addSortField("price", SolrQuery.ORDER.asc);
          q.addSortField("date", SolrQuery.ORDER.desc);
          q.addSortField("qty", SolrQuery.ORDER.desc);
          q.removeSortField("date", SolrQuery.ORDER.desc);
          Assert.assertEquals(2, q.getSortFields().length);
          q.removeSortField("qty", SolrQuery.ORDER.desc);
          q.removeSortField("price", SolrQuery.ORDER.asc);
          Assert.assertEquals(null, q.getSortFields());
        }
        

        The easiest (and also most robust) fix would be to use a white-space aware expression in getSortFields(), e.g. replacing s.split(",") with s.split(", *"), and reuse getSortField() inside removeSortField():

        public String[] getSortFields() {
          String s = getSortField();
          if (s==null) return null;
          return s.trim().split(", *");
        }
        
        public SolrQuery removeSortField(String field, ORDER order) {
          String[] sorts = getSortFields();
          if (sorts != null) {
            String removeSort = toSortString(field, order);
            String s = join(sorts, ", ", removeSort);
            if (s.length()==0) s=null;
            this.set(CommonParams.SORT, s);
          }
          return this;
        }
        

        I can include this fix in my patch under this jira, but I guess there might also be a desire for either a separate jira or a separate patch, or both. I don't know the Solr project culture on this, so I'm asking Otis and Yonik for advice. What do you guys think?

        Second, on the bigger suggestion from Yonik (to work on symbolic form rather than the serialized string), this will change some semantics, in that it is today possible to combine the use of .set("sort", "<somesortspec>") with addSortField(), removeSortField(), etc, and this will probably not be possible with the other api. It may get better, but it will change behaviour. My suggestion would be to apply this patch first, then think the other one properly through, including discussions on the list. Again, what do you guys think?

        Show
        Eirik Lygre added a comment - Things that seem simple sometimes are. Sometimes they're not First, I've found a bug in the current implementation of removeSortField() (not from my patch, but in the release). It works as follows: addSortField() concatinates the "sort" parameter, using a comma with no whitespace. Four fields would be "a asc,b asc,c asc,d asc" getSortFields() now returns a string array free from whitespace: [ "a asc", "b asc", "c asc", "d asc" ] removeSortField("c", ASC) first creates the partial string to remove, e.g. "c asc", then joins all getSortFields() not equal() the string, yielding [ "a asc", "b asc", "d asc" ] However, removeSortField() uses join with whitespace, creating "a asc, b asc, d asc" getSortFields() now returns [ "a asc", " b asc", " d asc"], with a space at the beginning of the last two elements removeSortField("b", ASC) will now fail, since the partial string "b asc" is not equal() the element " b asc" The problem can be shown in this (new) test case: public void testSolrQuerySortRemove() { SolrQuery q = new SolrQuery( "dog" ); q.addSortField( "price" , SolrQuery.ORDER.asc); q.addSortField( "date" , SolrQuery.ORDER.desc); q.addSortField( "qty" , SolrQuery.ORDER.desc); q.removeSortField( "date" , SolrQuery.ORDER.desc); Assert.assertEquals(2, q.getSortFields().length); q.removeSortField( "qty" , SolrQuery.ORDER.desc); q.removeSortField( "price" , SolrQuery.ORDER.asc); Assert.assertEquals( null , q.getSortFields()); } The easiest (and also most robust) fix would be to use a white-space aware expression in getSortFields(), e.g. replacing s.split(",") with s.split(", *") , and reuse getSortField() inside removeSortField(): public String [] getSortFields() { String s = getSortField(); if (s== null ) return null ; return s.trim().split( ", *" ); } public SolrQuery removeSortField( String field, ORDER order) { String [] sorts = getSortFields(); if (sorts != null ) { String removeSort = toSortString(field, order); String s = join(sorts, ", " , removeSort); if (s.length()==0) s= null ; this .set(CommonParams.SORT, s); } return this ; } I can include this fix in my patch under this jira, but I guess there might also be a desire for either a separate jira or a separate patch, or both. I don't know the Solr project culture on this, so I'm asking Otis and Yonik for advice. What do you guys think? Second, on the bigger suggestion from Yonik (to work on symbolic form rather than the serialized string), this will change some semantics, in that it is today possible to combine the use of .set("sort", "<somesortspec>") with addSortField(), removeSortField(), etc, and this will probably not be possible with the other api. It may get better, but it will change behaviour. My suggestion would be to apply this patch first, then think the other one properly through, including discussions on the list. Again, what do you guys think?
        Hide
        Eirik Lygre added a comment -

        Having published a couple of revisions on the dev mailing list, here is a proposed patch. It comprises the following:

        • Fixes to removeSortField() and getSortFields() (ref comments in this issue)
        • Deprecation of setSortField(), addSortField(), removeSortField(), getSortFields() and getSortField(), in favor of a map-based symbolic implementation
        • New symbolic sort api as shown below
        • Javadoc for the new api
        • Updated and new unit tests for all of the above
        SolrQuery setSorts(Map<String, ORDER> value);
        SolrQuery clearSorts();
        Map<String, ORDER> getSorts();
        SolrQuery setSort(String field, ORDER order);
        SolrQuery addSort(String field, ORDER order);
        SolrQuery addOrUpdateSort(String field, ORDER order);
        SolrQuery removeSort(String field);
        

        Based on the feedback to the initial patch, this revised patch is proposed for inclusion into the next release version (4.0.1) and above.

        Show
        Eirik Lygre added a comment - Having published a couple of revisions on the dev mailing list, here is a proposed patch. It comprises the following: Fixes to removeSortField() and getSortFields() (ref comments in this issue) Deprecation of setSortField(), addSortField(), removeSortField(), getSortFields() and getSortField(), in favor of a map-based symbolic implementation New symbolic sort api as shown below Javadoc for the new api Updated and new unit tests for all of the above SolrQuery setSorts(Map< String , ORDER> value); SolrQuery clearSorts(); Map< String , ORDER> getSorts(); SolrQuery setSort( String field, ORDER order); SolrQuery addSort( String field, ORDER order); SolrQuery addOrUpdateSort( String field, ORDER order); SolrQuery removeSort( String field); Based on the feedback to the initial patch, this revised patch is proposed for inclusion into the next release version (4.0.1) and above.
        Hide
        Eirik Lygre added a comment -

        Renaming and a minor optimization of the private function serializeSorts().

        Show
        Eirik Lygre added a comment - Renaming and a minor optimization of the private function serializeSorts().
        Hide
        Hoss Man added a comment -

        Eirik:

        Thanks for bring this up and working on improving things – I think the direction your patch is is taking looks really good, but i have a few comments that i think we should try to address before committing...

        1) the javadocs for the new methods should clarify that when they refer to "field" that can actually be any sortable value (ie: field names, function, "score", etc...)

        2) we should add javadocs to the deprecated methods explaining why they have been deprecated (ie: what limitations they have) with {@link} tags pointing out the corresponding new methods

        3) I don't actually see any advantage in deprecating/removing the "public String getSortField()" since it's read only ... we should just document that it returns the serialized value of the "sort" param and that for programatic access the new methods are available

        Lastly: I'm really not a fan of having "setSorts" and "getSorts" use "Map<String, ORDER>" in their APIs ... (I know, it was yonik's idea on the mailing list ... i cringed when i read that). Even if we're using LinkedHashMap unde the covers it seems like it would be far to easy for a naive user to let a HashMap make it's way to setSorts and then not understand why the final order isn't what they want.

        I think it would make a lot more sense to introduce a new tiny little immutable "SortClause" class that just models the String+ORDER pair, and have all of these methods take/return List<SortClause>. (It would also help simplify the javadocs for all these methods, because only the SortClause class would need to explain what the legal values are for the String, w/o cut/pasting on each of SolrQuery methods).

        What do you think?

        Show
        Hoss Man added a comment - Eirik: Thanks for bring this up and working on improving things – I think the direction your patch is is taking looks really good, but i have a few comments that i think we should try to address before committing... 1) the javadocs for the new methods should clarify that when they refer to "field" that can actually be any sortable value (ie: field names, function, "score", etc...) 2) we should add javadocs to the deprecated methods explaining why they have been deprecated (ie: what limitations they have) with {@link} tags pointing out the corresponding new methods 3) I don't actually see any advantage in deprecating/removing the "public String getSortField()" since it's read only ... we should just document that it returns the serialized value of the "sort" param and that for programatic access the new methods are available Lastly: I'm really not a fan of having "setSorts" and "getSorts" use "Map<String, ORDER>" in their APIs ... (I know, it was yonik's idea on the mailing list ... i cringed when i read that). Even if we're using LinkedHashMap unde the covers it seems like it would be far to easy for a naive user to let a HashMap make it's way to setSorts and then not understand why the final order isn't what they want. I think it would make a lot more sense to introduce a new tiny little immutable "SortClause" class that just models the String+ORDER pair, and have all of these methods take/return List<SortClause>. (It would also help simplify the javadocs for all these methods, because only the SortClause class would need to explain what the legal values are for the String, w/o cut/pasting on each of SolrQuery methods). What do you think?
        Hide
        Yonik Seeley added a comment -

        Lastly: I'm really not a fan of having "setSorts" and "getSorts" use "Map<String, ORDER>" in their APIs ... (I know, it was yonik's idea on the mailing list ... i cringed when i read that).

        I was just running with what seemed to be the implied requirement (which appeared to be random access-by-name to the sort criteria). Thinking about it a second longer though, I can't see any obvious use cases for that. List<SortClause> does seem more natural.

        Show
        Yonik Seeley added a comment - Lastly: I'm really not a fan of having "setSorts" and "getSorts" use "Map<String, ORDER>" in their APIs ... (I know, it was yonik's idea on the mailing list ... i cringed when i read that). I was just running with what seemed to be the implied requirement (which appeared to be random access-by-name to the sort criteria). Thinking about it a second longer though, I can't see any obvious use cases for that. List<SortClause> does seem more natural.
        Hide
        Eirik Lygre added a comment -

        I'll take the blame for guiding Yonik down the Map-path; at the time (while parsing the sort-field), returning a LinkedHashMap was an easy way to achieve the business objectives. Then, as the idea developed, it became less so. Anyway, that's why we review, right?

        Here is an extended view of my current implementation. It will probably not be like this, ref questions below

        public String getSortField();
        
        public SolrQuery setSorts(List<SortClause> value);
        public SolrQuery clearSorts();
        public List<SortClause> getSorts();
        public SolrQuery setSort(SortClause sortClause);
        public SolrQuery addSort(SortClause sortClause);
        public SolrQuery addOrUpdateSort(SortClause sortClause);
        public SolrQuery removeSort(String itemName);
        
        public static class SortClause {
          public static SortClause create (String item, ORDER order);
          public static SortClause create (String item, String order)
          public static SortClause asc (String item);
          public static SortClause desc (String item);
          public String getItem();
          public ORDER getOrder();
        }
        

        Some questions, illustrated by code examples. Some questions relate to apis shown above, and are REMOVE? questions; some questions relate to apis not shown above, and are ADD? questions. Note that some of the examples use stuff from other

        // Usage, per the api above
        query.setSort(SolrQuery.SortClause.desc("rating"));
        query.setSort(SolrQuery.SortClause.create("rating", SolrQuery.ORDER.desc));
        query.setSort(SolrQuery.SortClause.create("rating", SortQuery.ORDER.valueOf("desc")));
        query.setSort(SolrQuery.SortClause.create("rating", "asc"));
        query.remove("rating");
        

        I want to retain query.removeSort(String), because that's really the use case (remove sort based on item name, ignoring ordering). I'm not really sure about query.removeSort(SortClause), which does in fact only use the item name, but it would be symmetrical to the add-functions.

        // Q1: Should we REMOVE query.removeSort (String)
        query.addSort(new SolrQuery.SortClause("rating", SolrQuery.ORDER.desc));
        query.addSort(new SolrQuery.SortClause("price", SolrQuery.ORDER.asc));
        query.removeSort("rating");
        
        // Q2: Should we ADD query.removeSort(SortClause)?
        query.addSort(new SolrQuery.SortClause("rating", SolrQuery.ORDER.desc));
        query.addSort(new SolrQuery.SortClause("price", SolrQuery.ORDER.asc));
        query.removeSort(new SolrQuery.SortClause("price", SolrQuery.ORDER.desc));	// Remove irregardless of order
        

        We might build convenience functions query.xxxSort (String, order) and query.xxxSort (String,String) as shown below. It would make usage simpler, but come with a footprint. The SortClause.asc(), .desc() and .create() factory functions described below make this less needed, I think:

        // Q3: Should we ADD convenience functions query.xxxSort (String, order)
        query.addSort("price", SolrQuery.ORDER.asc);
        
        // Q4: Should we ADD convenience functions query.xxxSort (String, String)
        query.addSort("price", "asc");
        

        The api currently has convenience functions for creating SortClause. The functions asc() and desc() make it easier (and more compact) to create SortClause. The create() functions are there for symmetry (always use static methods instead of constructors). The constructors aren't public, but maybe they should be?

        // Q5: Should we REMOVE asc() and desc() convenience factory methods:
        query.setSort(SolrQuery.SortClause.desc("rating"));
        query.setSort(SolrQuery.SortClause.asc("rating"));
        
        // Q6: Should we REMOVE create(String,ORDER) convenience factory method (use constructor instead)
        query.setSort(SolrQuery.SortClause.create("rating", SolrQuery.ORDER.desc));
        query.setSort(SolrQuery.SortClause.create("rating", SolrQuery.ORDER.valueOf("desc")));
        
        // Q7:Should we REMOVE create(String,ORDER) convenience factory method (Complements Q5, when the order is in fact a string)
        query.setSort(SolrQuery.SortClause.create("rating", "desc"));
        
        // Q8: Should we ADD a simple constructor, typically instead of Q5-Q7?
        query.setSort(new SolrQuery.SortClause("rating", SolrQuery.ORDER.desc));
        query.setSort(new SolrQuery.SortClause("rating", SolrQuery.ORDER.valueOf("desc")));
        

        A couple of other items:

        Q9: Currently, SortClause is an inner class of SolrQuery. Let me know if this is an issue
        Q10: What the heck do we call "the thing to sort". I don't want to call it a "field", since it can be many other things. I've chosen to call it an "item", but is there another, better name?
        Q11: Should we have SortClause.hashCode() and SortClause.equals()?

        Show
        Eirik Lygre added a comment - I'll take the blame for guiding Yonik down the Map-path; at the time (while parsing the sort-field), returning a LinkedHashMap was an easy way to achieve the business objectives. Then, as the idea developed, it became less so. Anyway, that's why we review, right? Here is an extended view of my current implementation. It will probably not be like this, ref questions below public String getSortField(); public SolrQuery setSorts(List<SortClause> value); public SolrQuery clearSorts(); public List<SortClause> getSorts(); public SolrQuery setSort(SortClause sortClause); public SolrQuery addSort(SortClause sortClause); public SolrQuery addOrUpdateSort(SortClause sortClause); public SolrQuery removeSort( String itemName); public static class SortClause { public static SortClause create ( String item, ORDER order); public static SortClause create ( String item, String order) public static SortClause asc ( String item); public static SortClause desc ( String item); public String getItem(); public ORDER getOrder(); } Some questions, illustrated by code examples. Some questions relate to apis shown above, and are REMOVE? questions; some questions relate to apis not shown above, and are ADD? questions. Note that some of the examples use stuff from other // Usage, per the api above query.setSort(SolrQuery.SortClause.desc( "rating" )); query.setSort(SolrQuery.SortClause.create( "rating" , SolrQuery.ORDER.desc)); query.setSort(SolrQuery.SortClause.create( "rating" , SortQuery.ORDER.valueOf( "desc" ))); query.setSort(SolrQuery.SortClause.create( "rating" , "asc" )); query.remove( "rating" ); I want to retain query.removeSort(String), because that's really the use case (remove sort based on item name, ignoring ordering). I'm not really sure about query.removeSort(SortClause), which does in fact only use the item name, but it would be symmetrical to the add-functions. // Q1: Should we REMOVE query.removeSort ( String ) query.addSort( new SolrQuery.SortClause( "rating" , SolrQuery.ORDER.desc)); query.addSort( new SolrQuery.SortClause( "price" , SolrQuery.ORDER.asc)); query.removeSort( "rating" ); // Q2: Should we ADD query.removeSort(SortClause)? query.addSort( new SolrQuery.SortClause( "rating" , SolrQuery.ORDER.desc)); query.addSort( new SolrQuery.SortClause( "price" , SolrQuery.ORDER.asc)); query.removeSort( new SolrQuery.SortClause( "price" , SolrQuery.ORDER.desc)); // Remove irregardless of order We might build convenience functions query.xxxSort (String, order) and query.xxxSort (String,String) as shown below. It would make usage simpler, but come with a footprint. The SortClause.asc(), .desc() and .create() factory functions described below make this less needed, I think: // Q3: Should we ADD convenience functions query.xxxSort ( String , order) query.addSort( "price" , SolrQuery.ORDER.asc); // Q4: Should we ADD convenience functions query.xxxSort ( String , String ) query.addSort( "price" , "asc" ); The api currently has convenience functions for creating SortClause. The functions asc() and desc() make it easier (and more compact) to create SortClause. The create() functions are there for symmetry (always use static methods instead of constructors). The constructors aren't public, but maybe they should be? // Q5: Should we REMOVE asc() and desc() convenience factory methods: query.setSort(SolrQuery.SortClause.desc( "rating" )); query.setSort(SolrQuery.SortClause.asc( "rating" )); // Q6: Should we REMOVE create( String ,ORDER) convenience factory method (use constructor instead) query.setSort(SolrQuery.SortClause.create( "rating" , SolrQuery.ORDER.desc)); query.setSort(SolrQuery.SortClause.create( "rating" , SolrQuery.ORDER.valueOf( "desc" ))); // Q7:Should we REMOVE create( String ,ORDER) convenience factory method (Complements Q5, when the order is in fact a string) query.setSort(SolrQuery.SortClause.create( "rating" , "desc" )); // Q8: Should we ADD a simple constructor, typically instead of Q5-Q7? query.setSort( new SolrQuery.SortClause( "rating" , SolrQuery.ORDER.desc)); query.setSort( new SolrQuery.SortClause( "rating" , SolrQuery.ORDER.valueOf( "desc" ))); A couple of other items: Q9: Currently, SortClause is an inner class of SolrQuery. Let me know if this is an issue Q10: What the heck do we call "the thing to sort". I don't want to call it a "field", since it can be many other things. I've chosen to call it an "item", but is there another, better name? Q11: Should we have SortClause.hashCode() and SortClause.equals()?
        Hide
        Eirik Lygre added a comment -

        This patch implements the API as discussed above. The patch contains javadoc and unit tests, and was built against http://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x.

        This patch solves the original requirements that led to this issue (introspection of active sorts), and hopefully also the requirements of the Solr project (as represented by Yonik Seeley and Hoss Man).

        Show
        Eirik Lygre added a comment - This patch implements the API as discussed above. The patch contains javadoc and unit tests, and was built against http://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x . This patch solves the original requirements that led to this issue (introspection of active sorts), and hopefully also the requirements of the Solr project (as represented by Yonik Seeley and Hoss Man ).
        Hide
        Erick Erickson added a comment -

        I'll go ahead and shepherd this through the commit process, run all the unit tests and all that stuff unless people have objections..

        Show
        Erick Erickson added a comment - I'll go ahead and shepherd this through the commit process, run all the unit tests and all that stuff unless people have objections..
        Hide
        Steve Rowe added a comment -

        Erick, should this be pushed to 4.2?

        Show
        Steve Rowe added a comment - Erick, should this be pushed to 4.2?
        Hide
        Eirik Lygre added a comment -

        Now that 4.1 is out, could this be integrated and committed into the 4.2. The sooner it gets in, the more quality testing time people get to have with it!

        Show
        Eirik Lygre added a comment - Now that 4.1 is out, could this be integrated and committed into the 4.2. The sooner it gets in, the more quality testing time people get to have with it!
        Hide
        Erick Erickson added a comment -

        Eirik:

        Thanks for prompting me, I should have it in place this weekend at the latest.

        Erick

        Show
        Erick Erickson added a comment - Eirik: Thanks for prompting me, I should have it in place this weekend at the latest. Erick
        Hide
        Erick Erickson added a comment -

        Changed comments to "since 4.2" since I didn't get this done promptly.

        Tests pass on trunk, if there are no objections I'll commit this tomorrow (Friday).

        Show
        Erick Erickson added a comment - Changed comments to "since 4.2" since I didn't get this done promptly. Tests pass on trunk, if there are no objections I'll commit this tomorrow (Friday).
        Hide
        Commit Tag Bot added a comment -

        [trunk commit] Erick Erickson
        http://svn.apache.org/viewvc?view=revision&revision=1438977

        Fix for SOLR-3926, thanks Eirik

        Show
        Commit Tag Bot added a comment - [trunk commit] Erick Erickson http://svn.apache.org/viewvc?view=revision&revision=1438977 Fix for SOLR-3926 , thanks Eirik
        Hide
        Erick Erickson added a comment -

        trunk: r - 1438977
        4x: r - 1438986

        Also added to CHANGES.txt

        Thanks Eirik! And I have to admit this variant of Erik/Erick/Eric/Erich is a new one for me, but there can never be too many of these in the world <G>...

        Show
        Erick Erickson added a comment - trunk: r - 1438977 4x: r - 1438986 Also added to CHANGES.txt Thanks Eirik! And I have to admit this variant of Erik/Erick/Eric/Erich is a new one for me, but there can never be too many of these in the world <G>...
        Hide
        Commit Tag Bot added a comment -

        [branch_4x commit] Erick Erickson
        http://svn.apache.org/viewvc?view=revision&revision=1438986

        Fix for SOLR-3926, thanks Eirik

        Show
        Commit Tag Bot added a comment - [branch_4x commit] Erick Erickson http://svn.apache.org/viewvc?view=revision&revision=1438986 Fix for SOLR-3926 , thanks Eirik
        Hide
        Uwe Schindler added a comment -

        Closed after release.

        Show
        Uwe Schindler added a comment - Closed after release.

          People

          • Assignee:
            Erick Erickson
            Reporter:
            Eirik Lygre
          • Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development