[jira] [Created] (SOLR-12659) HttpSolrClient.createMethod does not handle both stream and large data
Eirik Lygre created SOLR-12659:
--
Summary: HttpSolrClient.createMethod does not handle both stream
and large data
Key: SOLR-12659
URL: https://issues.apache.org/jira/browse/SOLR-12659
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: SolrJ
Affects Versions: 7.4, 6.6.2
Reporter: Eirik Lygre
When using a ContentStreamUpdateRequest with stream data (through
addContentStream()), all other parameters are passed on the URL, leading to the
server failing with "URI is too large".
The code below provokes the error using Solrj 7.4, but was first seen on Solr
6.6.2. The problem is in HttpSolrClient.createMethod(), where the presence of
stream data leads to all other fields being put on the URL
h2. Example code
{code:java}
String stringValue = StringUtils.repeat('X', 16*1024);
SolrClient solr = new HttpSolrClient.Builder(BASE_URL).build();
ContentStreamUpdateRequest updateRequest = new
ContentStreamUpdateRequest("/update/extract");
updateRequest.setParam("literal.id", "UriTooLargeTest-simpleTest");
updateRequest.setParam("literal.field", stringValue);
updateRequest.addContentStream(new ContentStreamBase.StringStream(stringValue));
updateRequest.process(solr);
{code}
h2. The client sees the following error:
{code:java}
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
from server at http://server/solr/core: Expected mime type
application/octet-stream but got text/html. Bad Message
414reason: URI Too Long
{code}
h2. Error fragment from HttpSolrClient.createMethod
{code}
if(contentWriter != null) {
String fullQueryUrl = url + wparams.toQueryString();
HttpEntityEnclosingRequestBase postOrPut = SolrRequest.METHOD.POST ==
request.getMethod() ?
new HttpPost(fullQueryUrl) : new HttpPut(fullQueryUrl);
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-9230) Change of default to BinaryRequestWriter breaks some use cases
Eirik Lygre created SOLR-9230: - Summary: Change of default to BinaryRequestWriter breaks some use cases Key: SOLR-9230 URL: https://issues.apache.org/jira/browse/SOLR-9230 Project: Solr Issue Type: Bug Affects Versions: 6.0 Reporter: Eirik Lygre >From Solr 6.0 onwards, SOLR-8595 changes the default writer in HttpSolrClient >(et al) from RequestWriter to BinaryRequestWriter. The RequestWriter writes java.math.BigDecimal values using a simple toString() on the value. This means that a BigDecimal-value is passed to the server using its text representation, which is then mapped into whatever the server wants. (The RequestWriter probably uses toString() on anything it sees) The BinaryRequestWriter instead handles unknown value types by writing a string containing the class name, a colon, and then the toString() value. This means that a BigDecimal-value is passed to the server as a text representation "java.math.BigDecimal:12345", which the server cannot convert to a number, and which then stops indexing. I'm not entirely sure that this behaviour is a bug, but I'm fairly sure that the quiet change of behaviour qualifies. The "Trivial Patch" (quote from SOLR-8595) isn't, when straight forward indexing scenarios quietly stop working. There are several possible paths forward: * Have the BinaryRequestWriter (really the JavaBinCodec) encode java.lang.Numbers as Strings, the way the RequestWriter does * Add something in release notes to inform users about the change SOLR-4021 describes the problem, but the change of default writer increases problem visibility. SOLR-6165 somehow seems relevant. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-7664) Solrj client throws ParseException(Illegal content type) when server returns other http error (here 413) with BinaryResponseParser
Eirik Lygre created SOLR-7664: - Summary: Solrj client throws ParseException(Illegal content type) when server returns other http error (here 413) with BinaryResponseParser Key: SOLR-7664 URL: https://issues.apache.org/jira/browse/SOLR-7664 Project: Solr Issue Type: Bug Components: SolrJ Affects Versions: 5.2 Reporter: Eirik Lygre We have a program that uses Solrj to index data. For some as-of-yet undetermined reason, the server returns 413 FULL Head with no Content-Type header. When that happens, the Solrj library fails. In HttpSolrClient.executeMethod, two things happen: If there is no processor, then a RemoteSolrException is thrown, which is good. Ref https://github.com/apache/lucene-solr/blob/lucene_solr_5_2_0/solr/solrj/src/java/org/apache/solr/client/solrj/impl/HttpSolrClient.java#L493. However, with a processor, the code tries to call ContentType.parse() with the returned ContentType, which is null. This method throws a ParseException(Illegal content type), which propagates to the client. The cause of the error is very much hidden now. Ref https://github.com/apache/lucene-solr/blob/lucene_solr_5_2_0/solr/solrj/src/java/org/apache/solr/client/solrj/impl/HttpSolrClient.java#L513. It would be nice if the client would throw a RemoteSolrException in this case, too. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7664) Solrj client throws ParseException(Illegal content type) when server returns other http error (here 413) with BinaryResponseParser
[ https://issues.apache.org/jira/browse/SOLR-7664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Lygre updated SOLR-7664: -- Description: We have a program that uses Solrj to index data. For some (irrelevant) reason, the server sometimes returns 413 FULL Head with no Content-Type header. When that happens, the Solrj library fails. In HttpSolrClient.executeMethod, two things happen: If there is no processor, then a RemoteSolrException is thrown, which is good. Ref https://github.com/apache/lucene-solr/blob/lucene_solr_5_2_0/solr/solrj/src/java/org/apache/solr/client/solrj/impl/HttpSolrClient.java#L493. However, with a processor, the code tries to call ContentType.parse() with the returned ContentType, which is null. This method throws a ParseException(Illegal content type), which propagates to the client. The cause of the error is very much hidden now. Ref https://github.com/apache/lucene-solr/blob/lucene_solr_5_2_0/solr/solrj/src/java/org/apache/solr/client/solrj/impl/HttpSolrClient.java#L513. It would be nice if the client would throw a RemoteSolrException in this case, too. was: We have a program that uses Solrj to index data. For some as-of-yet undetermined reason, the server returns 413 FULL Head with no Content-Type header. When that happens, the Solrj library fails. In HttpSolrClient.executeMethod, two things happen: If there is no processor, then a RemoteSolrException is thrown, which is good. Ref https://github.com/apache/lucene-solr/blob/lucene_solr_5_2_0/solr/solrj/src/java/org/apache/solr/client/solrj/impl/HttpSolrClient.java#L493. However, with a processor, the code tries to call ContentType.parse() with the returned ContentType, which is null. This method throws a ParseException(Illegal content type), which propagates to the client. The cause of the error is very much hidden now. Ref https://github.com/apache/lucene-solr/blob/lucene_solr_5_2_0/solr/solrj/src/java/org/apache/solr/client/solrj/impl/HttpSolrClient.java#L513. It would be nice if the client would throw a RemoteSolrException in this case, too. Solrj client throws ParseException(Illegal content type) when server returns other http error (here 413) with BinaryResponseParser -- Key: SOLR-7664 URL: https://issues.apache.org/jira/browse/SOLR-7664 Project: Solr Issue Type: Bug Components: SolrJ Affects Versions: 5.2 Reporter: Eirik Lygre We have a program that uses Solrj to index data. For some (irrelevant) reason, the server sometimes returns 413 FULL Head with no Content-Type header. When that happens, the Solrj library fails. In HttpSolrClient.executeMethod, two things happen: If there is no processor, then a RemoteSolrException is thrown, which is good. Ref https://github.com/apache/lucene-solr/blob/lucene_solr_5_2_0/solr/solrj/src/java/org/apache/solr/client/solrj/impl/HttpSolrClient.java#L493. However, with a processor, the code tries to call ContentType.parse() with the returned ContentType, which is null. This method throws a ParseException(Illegal content type), which propagates to the client. The cause of the error is very much hidden now. Ref https://github.com/apache/lucene-solr/blob/lucene_solr_5_2_0/solr/solrj/src/java/org/apache/solr/client/solrj/impl/HttpSolrClient.java#L513. It would be nice if the client would throw a RemoteSolrException in this case, too. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7664) Solrj client throws ParseException(Illegal content type) when server returns other http error (here 413) with BinaryResponseParser
[ https://issues.apache.org/jira/browse/SOLR-7664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14581711#comment-14581711 ] Eirik Lygre commented on SOLR-7664: --- See also http://codingtricks.fidibuy.com/participant/join/54fce329b760506d5d9e7db3/Spring-Data-Solr-cannot-handle-long-queries for another user who experienced the same problem. Solrj client throws ParseException(Illegal content type) when server returns other http error (here 413) with BinaryResponseParser -- Key: SOLR-7664 URL: https://issues.apache.org/jira/browse/SOLR-7664 Project: Solr Issue Type: Bug Components: SolrJ Affects Versions: 5.2 Reporter: Eirik Lygre We have a program that uses Solrj to index data. For some as-of-yet undetermined reason, the server returns 413 FULL Head with no Content-Type header. When that happens, the Solrj library fails. In HttpSolrClient.executeMethod, two things happen: If there is no processor, then a RemoteSolrException is thrown, which is good. Ref https://github.com/apache/lucene-solr/blob/lucene_solr_5_2_0/solr/solrj/src/java/org/apache/solr/client/solrj/impl/HttpSolrClient.java#L493. However, with a processor, the code tries to call ContentType.parse() with the returned ContentType, which is null. This method throws a ParseException(Illegal content type), which propagates to the client. The cause of the error is very much hidden now. Ref https://github.com/apache/lucene-solr/blob/lucene_solr_5_2_0/solr/solrj/src/java/org/apache/solr/client/solrj/impl/HttpSolrClient.java#L513. It would be nice if the client would throw a RemoteSolrException in this case, too. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7664) Solrj client throws ParseException(Illegal content type) when server returns other http error (here 413) with BinaryResponseParser
[ https://issues.apache.org/jira/browse/SOLR-7664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Lygre updated SOLR-7664: -- Description: We have a program that uses Solrj to index data. For some (irrelevant) reason, the server sometimes returns 413 FULL Head with no Content-Type header. When that happens, the Solrj library fails. In HttpSolrClient.executeMethod, two things happen: If there is no processor, then a RemoteSolrException is thrown, which is good. Ref https://github.com/apache/lucene-solr/blob/lucene_solr_5_2_0/solr/solrj/src/java/org/apache/solr/client/solrj/impl/HttpSolrClient.java#L493. However, when there is a processor, the code tries to call ContentType.parse() with the returned ContentType, which is null. This method throws a ParseException(Illegal content type), which propagates to the client. The cause of the error is very much hidden now. Ref https://github.com/apache/lucene-solr/blob/lucene_solr_5_2_0/solr/solrj/src/java/org/apache/solr/client/solrj/impl/HttpSolrClient.java#L513. It would be nice if the client would throw a RemoteSolrException in this case, too. was: We have a program that uses Solrj to index data. For some (irrelevant) reason, the server sometimes returns 413 FULL Head with no Content-Type header. When that happens, the Solrj library fails. In HttpSolrClient.executeMethod, two things happen: If there is no processor, then a RemoteSolrException is thrown, which is good. Ref https://github.com/apache/lucene-solr/blob/lucene_solr_5_2_0/solr/solrj/src/java/org/apache/solr/client/solrj/impl/HttpSolrClient.java#L493. However, with a processor, the code tries to call ContentType.parse() with the returned ContentType, which is null. This method throws a ParseException(Illegal content type), which propagates to the client. The cause of the error is very much hidden now. Ref https://github.com/apache/lucene-solr/blob/lucene_solr_5_2_0/solr/solrj/src/java/org/apache/solr/client/solrj/impl/HttpSolrClient.java#L513. It would be nice if the client would throw a RemoteSolrException in this case, too. Solrj client throws ParseException(Illegal content type) when server returns other http error (here 413) with BinaryResponseParser -- Key: SOLR-7664 URL: https://issues.apache.org/jira/browse/SOLR-7664 Project: Solr Issue Type: Bug Components: SolrJ Affects Versions: 5.2 Reporter: Eirik Lygre We have a program that uses Solrj to index data. For some (irrelevant) reason, the server sometimes returns 413 FULL Head with no Content-Type header. When that happens, the Solrj library fails. In HttpSolrClient.executeMethod, two things happen: If there is no processor, then a RemoteSolrException is thrown, which is good. Ref https://github.com/apache/lucene-solr/blob/lucene_solr_5_2_0/solr/solrj/src/java/org/apache/solr/client/solrj/impl/HttpSolrClient.java#L493. However, when there is a processor, the code tries to call ContentType.parse() with the returned ContentType, which is null. This method throws a ParseException(Illegal content type), which propagates to the client. The cause of the error is very much hidden now. Ref https://github.com/apache/lucene-solr/blob/lucene_solr_5_2_0/solr/solrj/src/java/org/apache/solr/client/solrj/impl/HttpSolrClient.java#L513. It would be nice if the client would throw a RemoteSolrException in this case, too. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3926) solrj should support better way of finding active sorts
[
https://issues.apache.org/jira/browse/SOLR-3926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13560943#comment-13560943
]
Eirik Lygre commented on SOLR-3926:
---
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!
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
Assignee: Erick Erickson
Priority: Minor
Fix For: 4.2
Attachments: SOLR-3926.patch, 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 MapString,ORDER
getSortFieldMap();}} which returns an ordered map of active sort fields. This
will make introspection of the current sort setup much easier.
{code}
public MapString, ORDER getSortFieldMap() {
String[] actualSortFields = getSortFields();
if (actualSortFields == null || actualSortFields.length == 0)
return Collections.emptyMap();
MapString, ORDER sortFieldMap = new LinkedHashMapString, 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);
MapString, 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
Could we get SOLR-3926 submitted?
A little over a month ago I submitted patch under the issue https://issues.apache.org/jira/browse/SOLR-3926. After comments from Yonik and Hoss it was significantly rewritten, and a latest version was submitted on 4 December. Is there anything I can do to help complete the process of committing this patch? -- Eirik There is no high like a tango high There is no low like a tango low
Status of SOLR-3926
A little over a month ago I submitted patch under the issue https://issues.apache.org/jira/browse/SOLR-3926. After comments from Yonik and Hoss it was significantly rewritten, and a latest version was submitted on 4 December. Is there anything I can do to help complete the process of committing this patch? -- Eirik There is no high like a tango high There is no low like a tango low
[jira] [Updated] (SOLR-3926) solrj should support better way of finding active sorts
[
https://issues.apache.org/jira/browse/SOLR-3926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eirik Lygre updated SOLR-3926:
--
Attachment: SOLR-3926.patch
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 [~yo...@apache.org] and [~hossman]).
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,
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 MapString,ORDER
getSortFieldMap();}} which returns an ordered map of active sort fields. This
will make introspection of the current sort setup much easier.
{code}
public MapString, ORDER getSortFieldMap() {
String[] actualSortFields = getSortFields();
if (actualSortFields == null || actualSortFields.length == 0)
return Collections.emptyMap();
MapString, ORDER sortFieldMap = new LinkedHashMapString, 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);
MapString, 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
[jira] [Commented] (SOLR-3926) solrj should support better way of finding active sorts
[
https://issues.apache.org/jira/browse/SOLR-3926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505483#comment-13505483
]
Eirik Lygre commented on SOLR-3926:
---
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 :-)
{code}
public String getSortField();
public SolrQuery setSorts(ListSortClause value);
public SolrQuery clearSorts();
public ListSortClause 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();
}
{code}
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
{code}
// 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);
{code}
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.
{code}
// 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
{code}
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:
{code}
// 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);
{code}
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?
{code}
// 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)));
{code}
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()?
solrj should support better way of finding active sorts
---
Key: SOLR-3926
URL: https://issues.apache.org/jira/browse/SOLR-3926
[jira] [Updated] (SOLR-3926) solrj should support better way of finding active sorts
[
https://issues.apache.org/jira/browse/SOLR-3926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eirik Lygre updated SOLR-3926:
--
Attachment: SOLR-3926.patch
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
{code}
SolrQuery setSorts(MapString, ORDER value);
SolrQuery clearSorts();
MapString, ORDER getSorts();
SolrQuery setSort(String field, ORDER order);
SolrQuery addSort(String field, ORDER order);
SolrQuery addOrUpdateSort(String field, ORDER order);
SolrQuery removeSort(String field);
{code}
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.
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
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 MapString,ORDER
getSortFieldMap();}} which returns an ordered map of active sort fields. This
will make introspection of the current sort setup much easier.
{code}
public MapString, ORDER getSortFieldMap() {
String[] actualSortFields = getSortFields();
if (actualSortFields == null || actualSortFields.length == 0)
return Collections.emptyMap();
MapString, ORDER sortFieldMap = new LinkedHashMapString, 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);
MapString, 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
Re: Patch for SOLR-3926: A better way to get current sort information from solrj.SolrQuery
I have added a proposed patch to the jira issue, at https://issues.apache.org/jira/browse/SOLR-3926?focusedCommentId=13502346page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13502346 . The proposed satisfies my original needs, using a symbolic api as proposed by Yonik. I'm hoping this is now sufficiently well developed to be applied to both the 4x-branch and the trunk moving forward. On Mon, Nov 19, 2012 at 5:09 PM, Eirik Lygre eirik.ly...@gmail.com wrote: On Mon, Nov 19, 2012 at 3:23 PM, Eirik Lygre eirik.ly...@gmail.comwrote: On Sat, Nov 17, 2012 at 11:41 AM, Eirik Lygre eirik.ly...@gmail.comwrote: // Functional, symbolic api. Changes are serialized immediately MapString, ORDER getSort() // Returns immmutable, ordered map setSort(LinkedHashMapS,O); addSort(String, ORDER); removeSort(); removeSort(String); So, a couple of questions out of this: - Do we want to maintain backward compatibility i.e. the use case with setting the string and then manipulating it? - Is there a clear point for serialization, so that we can serialize at the end only? Two comments for the api: 1) There is a use case that might be fairly common, in which first a number of sorts are set, and then the user wants to change the direction of that sort. Presumably this happens over time, and over several user interactions, but it would probably look like this: q.addSort (a, ASC).addSort(b, ASC).addSort(c, ASC); // Now change the sort order of a, while maintaining a as the first field in the sort list q.setSort(a, DESC); // Don't like; setSort() feels like it should remove others q.toggleSort(a); // Works, but I'd prefer an api where I decide the direction (e.g. not toggle) q.toggleSort(a, DESC) // Works, but the word toggle is not really good q.changeSort(a, DESC); // Works, though it is not clear what to do if a is not already in the sort list q.changeOrAddSort(a, DESC); // This is my preferred semantics, but what about the method name? q.setSort(new LinkedHashMap(q.getSort()) 2) Also, I'm not sure I like the method name removeSort() to remove all. Either removeAllSorts() or clearSort(), with a preference to the latter (it matches clear() which is used to clear the entire SolrQuery/ModifiableSolrParams) // Functional, symbolic api. Changes are serialized immediately clearSort(); MapString, ORDER getSort() // Returns immutable, ordered map setSort(LinkedHashMapS,O); addSort(String, ORDER); changeOrAddSort (String, ORDER) removeSort(String); Attached is a patch; I'll put it up on jira once we're kinda happy with it :-) 1) I renamed the new method (#1 above) to addOrUpdateSort(). Probably not a particularly good parallel, but I found org.apache.lucene.index.FieldInfos.addOrUpdate(), and reused that convention 2) I removed the new raw string methods getSortString() and setSortString(). The point of this exercise is to use a symbolic api, and if you want the raw field, use get()/set() with CommonParams.SORT. The attached patch now contains a few fixes to the old api, tests for those fixes, the new api with javadoc, and tests for the new api. -- Eirik There is no high like a tango high There is no low like a tango low -- Eirik There is no high like a tango high There is no low like a tango low
[jira] [Updated] (SOLR-3926) solrj should support better way of finding active sorts
[
https://issues.apache.org/jira/browse/SOLR-3926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eirik Lygre updated SOLR-3926:
--
Attachment: SOLR-3926.patch
Renaming and a minor optimization of the private function serializeSorts().
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 MapString,ORDER
getSortFieldMap();}} which returns an ordered map of active sort fields. This
will make introspection of the current sort setup much easier.
{code}
public MapString, ORDER getSortFieldMap() {
String[] actualSortFields = getSortFields();
if (actualSortFields == null || actualSortFields.length == 0)
return Collections.emptyMap();
MapString, ORDER sortFieldMap = new LinkedHashMapString, 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);
MapString, 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
Re: Patch for SOLR-3926: A better way to get current sort information from solrj.SolrQuery
On Sat, Nov 17, 2012 at 11:41 AM, Eirik Lygre eirik.ly...@gmail.com wrote: // Functional, symbolic api. Changes are serialized immediately MapString, ORDER getSort() // Returns immmutable, ordered map setSort(LinkedHashMapS,O); addSort(String, ORDER); removeSort(); removeSort(String); So, a couple of questions out of this: - Do we want to maintain backward compatibility i.e. the use case with setting the string and then manipulating it? - Is there a clear point for serialization, so that we can serialize at the end only? Two comments for the api: 1) There is a use case that might be fairly common, in which first a number of sorts are set, and then the user wants to change the direction of that sort. Presumably this happens over time, and over several user interactions, but it would probably look like this: q.addSort (a, ASC).addSort(b, ASC).addSort(c, ASC); // Now change the sort order of a, while maintaining a as the first field in the sort list q.setSort(a, DESC); // Don't like; setSort() feels like it should remove others q.toggleSort(a); // Works, but I'd prefer an api where I decide the direction (e.g. not toggle) q.toggleSort(a, DESC) // Works, but the word toggle is not really good q.changeSort(a, DESC); // Works, though it is not clear what to do if a is not already in the sort list q.changeOrAddSort(a, DESC); // This is my preferred semantics, but what about the method name? q.setSort(new LinkedHashMap(q.getSort()) 2) Also, I'm not sure I like the method name removeSort() to remove all. Either removeAllSorts() or clearSort(), with a preference to the latter (it matches clear() which is used to clear the entire SolrQuery/ModifiableSolrParams) // Functional, symbolic api. Changes are serialized immediately clearSort(); MapString, ORDER getSort() // Returns immutable, ordered map setSort(LinkedHashMapS,O); addSort(String, ORDER); changeOrAddSort (String, ORDER) removeSort(String); -- Eirik There is no high like a tango high There is no low like a tango low
Re: Patch for SOLR-3926: A better way to get current sort information from solrj.SolrQuery
On Mon, Nov 19, 2012 at 3:23 PM, Eirik Lygre eirik.ly...@gmail.com wrote: On Sat, Nov 17, 2012 at 11:41 AM, Eirik Lygre eirik.ly...@gmail.comwrote: // Functional, symbolic api. Changes are serialized immediately MapString, ORDER getSort() // Returns immmutable, ordered map setSort(LinkedHashMapS,O); addSort(String, ORDER); removeSort(); removeSort(String); So, a couple of questions out of this: - Do we want to maintain backward compatibility i.e. the use case with setting the string and then manipulating it? - Is there a clear point for serialization, so that we can serialize at the end only? Two comments for the api: 1) There is a use case that might be fairly common, in which first a number of sorts are set, and then the user wants to change the direction of that sort. Presumably this happens over time, and over several user interactions, but it would probably look like this: q.addSort (a, ASC).addSort(b, ASC).addSort(c, ASC); // Now change the sort order of a, while maintaining a as the first field in the sort list q.setSort(a, DESC); // Don't like; setSort() feels like it should remove others q.toggleSort(a); // Works, but I'd prefer an api where I decide the direction (e.g. not toggle) q.toggleSort(a, DESC) // Works, but the word toggle is not really good q.changeSort(a, DESC); // Works, though it is not clear what to do if a is not already in the sort list q.changeOrAddSort(a, DESC); // This is my preferred semantics, but what about the method name? q.setSort(new LinkedHashMap(q.getSort()) 2) Also, I'm not sure I like the method name removeSort() to remove all. Either removeAllSorts() or clearSort(), with a preference to the latter (it matches clear() which is used to clear the entire SolrQuery/ModifiableSolrParams) // Functional, symbolic api. Changes are serialized immediately clearSort(); MapString, ORDER getSort() // Returns immutable, ordered map setSort(LinkedHashMapS,O); addSort(String, ORDER); changeOrAddSort (String, ORDER) removeSort(String); Attached is a patch; I'll put it up on jira once we're kinda happy with it :-) 1) I renamed the new method (#1 above) to addOrUpdateSort(). Probably not a particularly good parallel, but I found org.apache.lucene.index.FieldInfos.addOrUpdate(), and reused that convention 2) I removed the new raw string methods getSortString() and setSortString(). The point of this exercise is to use a symbolic api, and if you want the raw field, use get()/set() with CommonParams.SORT. The attached patch now contains a few fixes to the old api, tests for those fixes, the new api with javadoc, and tests for the new api. -- Eirik There is no high like a tango high There is no low like a tango low SOLR-3926.patch Description: Binary data - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Patch for SOLR-3926: A better way to get current sort information from solrj.SolrQuery
On Fri, Nov 16, 2012 at 4:57 PM, Yonik Seeley yo...@lucidworks.com wrote: On Fri, Nov 16, 2012 at 11:56 AM, Eirik Lygre eirik.ly...@gmail.com wrote: One way out would be to have a parallel set of methods that work on symbolic form: These new functions would not be able to parse a sort string, but they would handle more complex sort specifications. As a user of SolrQuery, you would use one, but not both, of these apis. That seems reasonable to me. Something like this perhaps? MapString, SORT_ORDER getSort() setSort(MapString, SORT_ORDER) String getSortString() void setSortString(String sortString) // throw exception if the internal Map isn't null? and add/removeSortField would only work on the internal Map (and throw an exception if setSortString had been used?) A couple of thoughts: 1) The old methods work on the serialized string. If we want to maintain backward compatibility (do we?), we can't really change that, because that supports a use case where you first set the full sort string, and then start manipulating them. 2) I'm not sure about the map-idea, but not all against it either :-) a) If we expose the Map as the api, we should probably specify that this is an ordered map; otherwise, people will make the common mistake of using a HashMap, inserting values in the order they want fields sorted, and get the unexpected result. As far as I know, that means specifying LinkedHashMap, right? b) We also need to decide on the point of serialization, and the mutability of the map returned from getSort(). - If it is mutable, I expect to be able to say query.getSort().put(field, ORDER.asc). For that to work, we need to have a clear serialization entry point, and I haven't found that. - If it is immutable, there will be some amount of copying maps which really isn't needed, perhaps c) I'm not sure about the value of the exception from setSortString; set(CommonParams.SORT, str) would presumably bypass that anyway, unless we override that, too. And, if we are to serialize the string as the map changes (which I think we might have to), we'll probably need some local (but simple) bookkeeping in order to keep track of the source of the sort string (symbolic vs raw api). If we were to maintain backward compatibility, I would think of something like this: // Functional, symbolic api. Changes are serialized immediately MapString, ORDER getSort() // Returns immmutable, ordered map setSort(LinkedHashMapS,O); addSort(String, ORDER); removeSort(); removeSort(String); // Raw string api, shortcuts to get()/set() with CommonParams.SORT void setSortString(String sortString) String getSortString() // @Deprecated api, parses the serialized string setSortField(String, ORDER) addSortField(String, ORDER) removeSortField(String, ORDER) String[] getSortFields() String getSortField() // Same as getSortString() If we skip backward compatibility (e.g. no use case with setting the string and then manipulating it), we get off easier, much like your suggestion: // Raw string api, shortcuts to get()/set() with CommonParams.SORT void setSortField(String sortString) // New String getSortField() // Functional, symbolic api, changes the serialized string MapString, ORDER getSort() // Returns immmutable, ordered map setSort(LinkedHashMap) setSortField(String, ORDER) addSortField(String, ORDER) removeSortField(String, ORDER) String[] getSortFields() // Array of serialized entries So, a couple of questions out of this: - Do we want to maintain backward compatibility i.e. the use case with setting the string and then manipulating it? - Is there a clear point for serialization, so that we can serialize at the end only? -- Eirik There is no high like a tango high There is no low like a tango low
Re: Patch for SOLR-3926: A better way to get current sort information from solrj.SolrQuery
(I wrote some more comments on the SolrQuery sorting functions in the jira itself; that should probably have been on the mailing list; sorry about that). The current state (described in https://issues.apache.org/jira/browse/SOLR-3926) is that there is a nice and clean (thanks, Otis!) little patch to extend SolrQuery's sorting methods. In the process of writing, testing and discussing that, I've found a couple of bugs in the original SolrQuery sorting methods, and Yonik had comments on the entire (current) approach to sort fields. The current SolrQuery implementations of addSortField()/removeSortField() use the sort parameter string stored in SolrQuery (really the parent ModifiableSolrParams), parsing it and changing it as needed. The methods assume that the string has a syntax of field direction,field direction,field direction, where comma is used to separate the entries. While this obviously covers the current use cases (or else they wouldn't work), it will fail as soon as we get into advanced functional sort, for example the sort string sum(x_f, y_f) desc, price asc would break SolrQuery.removeSortField() and SolrQuery.getSortFields() due to the comma inside the function. An alternative approach is suggested by Yonik: 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?. That should solve the problems outlined above. However, it would also probably not work well with a pattern that works today, where you can actually set the full sort string *as a string* on the SolrQuery, and then manipulate it. So, that will be a regression that may not be desirable. One way out would be to have a parallel set of methods that work on symbolic form: These new functions would not be able to parse a sort string, but they would handle more complex sort specifications. As a user of SolrQuery, you would use one, but not both, of these apis. think I would hope for the following approach: - Fist, I complete a patch that fixes the current bugs (with the current implementation) as well as the enhancement request in SOLR-3926, and we get that commited. - Afterwards, if we the people of this list thinks we should extend SolrQuery with better sort manipulation support, I'll volunteer to write additional methods as described above. Comments? And it would be nice to have a committer signed up for taking my patch in, when it's done. Eirik On Mon, Nov 12, 2012 at 9:35 PM, Eirik Lygre eirik.ly...@gmail.com wrote: Our search client needs to render the current search information from a SolrQuery object. The existing SolrQuery.getSortFields() method returns an array of strings of the form fieldname direction, which the client must parse itself. While this is not very difficult, it is orthogonal to the concept used for setting sort information, which is based on methods taking two parameters: fieldname and an enum indicating sort direction (SolrQuery.ORDER). The issue is logged as https://issues.apache.org/jira/browse/SOLR-3926. I have created a patch with a new method MapString, ORDER getSortFieldMap(). This method will parse the current search settings, and return a typed object which is easier to work with. The patch is created against the branch_4x code. It would be cool if a commiter could look at the issue and the code, and give some feedback, and hopefully promote the code into repository. If required, I will also create a similar patch for trunk. -- Eirik There is no high like a tango high There is no low like a tango low -- Eirik There is no high like a tango high There is no low like a tango low
[jira] [Created] (SOLR-4081) QueryParsing.toString(Query,IndexSchema) does not properly handle WrappedQuery
Eirik Lygre created SOLR-4081:
-
Summary: QueryParsing.toString(Query,IndexSchema) does not
properly handle WrappedQuery
Key: SOLR-4081
URL: https://issues.apache.org/jira/browse/SOLR-4081
Project: Solr
Issue Type: Bug
Components: query parsers
Affects Versions: 4.0
Reporter: Eirik Lygre
Priority: Minor
QueryParsing.toString() is a method that uses knowledge of various Query
implementations to properly render a query string. For example, using toString
with a BooleanQuery might return a string like this:
{{owner_id:18935 (acl_id:9451 acl_id:11634 acl_id:15678 acl_id:16791)}}
When using localParams such as {!cache=false cost=0}, the query turns into a
WrappedQuery wrapping a BooleanQuery. This is not understood by
QueryParsing.toString(), which calls WrappedQuery.toString() instead, returning
a string like this:
{{\{!cache=false cost=0}owner_id:w (acl_id:` acl_id:Ik acl_id:Zr acl_id:z
acl_id:\)}}
The probable (untested) solution will be to include a couple of lines at the
top of toString(), as shown below. A further optimization would be to create
void WrappedQuery.getOptions(Appendable out), to avoid creating a
StringBuilder inside WrappedQuery.getOptions().
{code}
public static void toString(Query query, IndexSchema schema, Appendable out,
int flags) throws IOException {
boolean writeBoost = true;
// Begin new code to handle WrappedQuery
if (query instanceof WrappedQuery) {
WrappedQuery q = (WrappedQuery)query;
out.append (q.getOptions());
query = q.getWrappedQuery();
}
// End new code to handle WrappedQuery
if (query instanceof TermQuery) {
...
{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
[jira] [Commented] (SOLR-3926) solrj should support better way of finding active sorts
[
https://issues.apache.org/jira/browse/SOLR-3926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 MapString,ORDER
getSortFieldMap();}} which returns an ordered map of active sort fields. This
will make introspection of the current sort setup much easier.
{code}
public MapString, ORDER getSortFieldMap() {
String[] actualSortFields = getSortFields();
if (actualSortFields == null || actualSortFields.length == 0)
return Collections.emptyMap();
MapString, ORDER sortFieldMap = new LinkedHashMapString, ORDER();
for (String sortField : actualSortFields) {
String[] fieldSpec = sortField.trim().split
[jira] [Commented] (SOLR-3926) solrj should support better way of finding active sorts
[
https://issues.apache.org/jira/browse/SOLR-3926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13496137#comment-13496137
]
Eirik Lygre commented on SOLR-3926:
---
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 ([~yo...@apache.org],
[~otis]) 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.
{code}
q.addSortField(price, SolrQuery.ORDER.asc);
q.addSortField(date, SolrQuery.ORDER.desc);
q.addSortField(qty, SolrQuery.ORDER.desc);
q.removeSortField(date, SolrQuery.ORDER.desc);
{code}
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 MapString,ORDER
getSortFieldMap();}} which returns an ordered map of active sort fields. This
will make introspection of the current sort setup much easier.
{code}
public MapString, ORDER getSortFieldMap() {
String[] actualSortFields = getSortFields();
if (actualSortFields == null || actualSortFields.length == 0)
return Collections.emptyMap();
MapString, ORDER sortFieldMap = new LinkedHashMapString, 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);
MapString, 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
[jira] [Comment Edited] (SOLR-3926) solrj should support better way of finding active sorts
[
https://issues.apache.org/jira/browse/SOLR-3926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13496137#comment-13496137
]
Eirik Lygre edited comment on SOLR-3926 at 11/13/12 12:36 PM:
--
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 ([~yo...@apache.org],
[~otis]?) 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.
{code}
q.addSortField(price, SolrQuery.ORDER.asc);
q.addSortField(date, SolrQuery.ORDER.desc);
q.addSortField(qty, SolrQuery.ORDER.desc);
q.removeSortField(date, SolrQuery.ORDER.desc);
{code}
was (Author: elygre):
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 ([~yo...@apache.org],
[~otis]) 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.
{code}
q.addSortField(price, SolrQuery.ORDER.asc);
q.addSortField(date, SolrQuery.ORDER.desc);
q.addSortField(qty, SolrQuery.ORDER.desc);
q.removeSortField(date, SolrQuery.ORDER.desc);
{code}
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 MapString,ORDER
getSortFieldMap();}} which returns an ordered map of active sort fields. This
will make introspection of the current sort setup much easier.
{code}
public MapString, ORDER getSortFieldMap() {
String[] actualSortFields = getSortFields();
if (actualSortFields == null || actualSortFields.length == 0)
return Collections.emptyMap();
MapString, ORDER sortFieldMap = new LinkedHashMapString, 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);
MapString, 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
[jira] [Updated] (SOLR-3926) solrj should support better way of finding active sorts
[
https://issues.apache.org/jira/browse/SOLR-3926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eirik Lygre updated SOLR-3926:
--
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:
{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 MapString,ORDER
getSortFieldMap();}} which returns an ordered map of active sort fields. This
will make introspection of the current sort setup much easier.
{code}
public MapString, ORDER getSortFieldMap() {
String[] actualSortFields = getSortFields();
if (actualSortFields == null || actualSortFields.length == 0)
return Collections.emptyMap();
MapString, ORDER sortFieldMap = new LinkedHashMapString, 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);
MapString, ORDER fieldMap = getSortFieldMap(query);
for (String field : fieldMap.keySet()) {
System.out.println(- + field + ; dir= + fieldMap.get(field));
}
{code}
was:
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 MapString,ORDER
getSortFieldMap();}} which returns an ordered map of active sort fields. An
example implementation is shown below (here as a utility method living outside
SolrQuery; the rewrite should be trivial)
{code}
public MapString, ORDER getSortFieldMap(SolrQuery query) {
String[] actualSortFields = query.getSortFields();
if (actualSortFields == null || actualSortFields.length == 0)
return Collections.emptyMap();
MapString, ORDER sortFieldMap = new LinkedHashMapString, ORDER();
for (String sortField : actualSortFields) {
String[] fieldSpec = sortField.split( );
sortFieldMap.put(fieldSpec[0], ORDER.valueOf(fieldSpec[1]));
}
return sortFieldMap;
}
{code}
For what it's worth, this is possible client code:
{code}
System.out.println(Active sorts);
MapString, ORDER fieldMap = getSortFieldMap(query);
for (String field : fieldMap.keySet()) {
System.out.println(- + field + ; dir= + fieldMap.get(field));
}
{code}
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
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 MapString,ORDER
getSortFieldMap();}} which returns
[jira] [Updated] (SOLR-3926) solrj should support better way of finding active sorts
[
https://issues.apache.org/jira/browse/SOLR-3926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eirik Lygre updated SOLR-3926:
--
Attachment: SOLR-3926.patch
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.
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
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 MapString,ORDER
getSortFieldMap();}} which returns an ordered map of active sort fields. This
will make introspection of the current sort setup much easier.
{code}
public MapString, ORDER getSortFieldMap() {
String[] actualSortFields = getSortFields();
if (actualSortFields == null || actualSortFields.length == 0)
return Collections.emptyMap();
MapString, ORDER sortFieldMap = new LinkedHashMapString, 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);
MapString, 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
[jira] [Updated] (SOLR-3926) solrj should support better way of finding active sorts
[
https://issues.apache.org/jira/browse/SOLR-3926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eirik Lygre updated SOLR-3926:
--
Affects Version/s: (was: 4.0-BETA)
4.0
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
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 MapString,ORDER
getSortFieldMap();}} which returns an ordered map of active sort fields. An
example implementation is shown below (here as a utility method living
outside SolrQuery; the rewrite should be trivial)
{code}
public MapString, ORDER getSortFieldMap(SolrQuery query) {
String[] actualSortFields = query.getSortFields();
if (actualSortFields == null || actualSortFields.length == 0)
return Collections.emptyMap();
MapString, ORDER sortFieldMap = new LinkedHashMapString, ORDER();
for (String sortField : actualSortFields) {
String[] fieldSpec = sortField.split( );
sortFieldMap.put(fieldSpec[0], ORDER.valueOf(fieldSpec[1]));
}
return sortFieldMap;
}
{code}
For what it's worth, this is possible client code:
{code}
System.out.println(Active sorts);
MapString, 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
[jira] [Created] (SOLR-3926) solrj should support better way of finding active sorts
Eirik Lygre created SOLR-3926:
-
Summary: 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-BETA
Reporter: Eirik Lygre
Priority: Minor
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 MapString,ORDER
getSortFieldMap();}} which returns an ordered map of active sort fields. An
example implementation is shown below (here as a utility method living outside
SolrQuery; the rewrite should be trivial)
{code}
public MapString, ORDER getSortFieldMap(SolrQuery query) {
String[] actualSortFields = query.getSortFields();
if (actualSortFields == null || actualSortFields.length == 0)
return Collections.emptyMap();
MapString, ORDER sortFieldMap = new LinkedHashMapString, ORDER();
for (String sortField : actualSortFields) {
String[] fieldSpec = sortField.split( );
sortFieldMap.put(fieldSpec[0], ORDER.valueOf(fieldSpec[1]));
}
return sortFieldMap;
}
{code}
For what it's worth, this is possible client code:
{code}
System.out.println(Active sorts);
MapString, 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
