[
https://issues.apache.org/jira/browse/SOLR-3926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504276#comment-13504276
]
Hoss Man commented on SOLR-3926:
--------------------------------
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?
> 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, SOLR-3926.patch, 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
