[
https://issues.apache.org/jira/browse/SOLR-3926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13498352#comment-13498352
]
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:
{code}
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());
}
{code}
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():
{code}
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;
}
{code}
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: https://issues.apache.org/jira/browse/SOLR-3926
> 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: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
