lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eirik Lygre (JIRA)" <>
Subject [jira] [Commented] (SOLR-3926) solrj should support better way of finding active sorts
Date Thu, 15 Nov 2012 21:29:13 GMT


Eirik Lygre commented on SOLR-3926:

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?

> solrj should support better way of finding active sorts
> -------------------------------------------------------
>                 Key: SOLR-3926
>                 URL:
>             Project: Solr
>          Issue Type: Improvement
>          Components: clients - java
>    Affects Versions: 4.0
>            Reporter: Eirik Lygre
>            Priority: Minor
>             Fix For: 4.1
>         Attachments: SOLR-3926.patch
> 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":
> {code}
> 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();
> {code}
> 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.
> {code}
>   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);
>   }
> {code}
> For what it's worth, this is possible client code:
> {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));
> }
> {code}

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message