The use cases that are important to me for my specific needs.
Generate a query string that can be passed to SolrJ's SolrQuery(String q).
During query generation the properties of the query can be manipulated.
For example:
title:"pink panther"^2 could be manipulated to be something different suc
I'm not sure I understand what it means to "support" the JSON request API
in solrj. Solrj is a Java interface. It should represent things in a manner
natural for java, and not tightly bound to any format. Solrj probably
should be better documented in the ref guide (solrj examples alongside the
v1 a
I did not use the term "legacy" to suggest we remove it. No no. Just in lack of
better name. Guess it could also be called http-parameter-request-api/dsl or
localparam-dsl, as opposed to JSON-request-api/dsl. "Lucene query string" is in
my mind the "+foo -(bar baz)~2" string, while our Solr quer
Since when is Solr’s, venerable “lucene” query syntax legacy? I don’t
imagine it would ever disappear.
On Tue, Aug 20, 2024 at 7:30 PM Geoffrey Slinker
wrote:
> I am very happy that a discussion is underway and that maybe in the end
> there will be new ways to generate queries for end users.
>
I am very happy that a discussion is underway and that maybe in the end there
will be new ways to generate queries for end users.
I am not in a position to speak for what is already “inside” Apache Solr.
If I can help please let me know.
Geoffrey
> On Aug 20, 2024, at 4:49 PM, Uwe Schindler w
+1: Thanks for this writeup, Jan!
Am 20.08.2024 um 22:49 schrieb Jan Høydahl:
Having written tons of Java client code for querying elasticsearch, one thing I
appreciate with the various QueryBuilders is how closely they map to the actual
Lucene Query objects being the end result. Also, they are
Having written tons of Java client code for querying elasticsearch, one thing I
appreciate with the various QueryBuilders is how closely they map to the actual
Lucene Query objects being the end result. Also, they are nicely composable,
and of course map almost 1:1 to ES JSON query dsl.
So if we w
Also if expressed as xml the lucene classes can be sent to solr (not sure
if we have a tool to express them as xml however)
https://solr.apache.org/guide/solr/latest/query-guide/other-parsers.html#xml-query-parser
On Tue, Aug 20, 2024 at 1:11 PM Mike Drob wrote:
> At the risk of sounding ignora
Your feed back is greatly appreciated.
The implementation that I have is the result of my very specific use cases
applied over several years.
My use cases may be so specialized that this isn't meaningful outside of my
domain. And that's okay.
I have use cases where a search request is converted
At the risk of sounding ignorant, what is the advantage of this over using
Lucene classes to programmatically build queries and then toString those?
It's not a single class, but the lucene search package has always seemed
pretty straightforward to me.
https://lucene.apache.org/core/9_7_0/core/org/a
Let's bikeshed before you write code, okay? Otherwise you potentially
waste time and/or grow attached to sunk costs.
Feedback:
* avoid the word "term"; it already has Lucene definition and a Solr
query parser but you're using it in a way that isn't either. I
recommend simply for "fieldQuery" --
I have added to SolrJ the ability to use objects to build query strings.
The current idea can be found in:
https://github.com/gslinker/solr/tree/SOLRJ_QUERY_BUILDER
Term and TermGroup are the foremost classes.
-
Term is a unit of search. It is composed of two elements, the valu
12 matches
Mail list logo
