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
Thanks, I'll take a look.
On Tue, 20 Aug, 2024, 11:22 pm David Smiley, wrote:
> Since the new multiThreaded search feature landed, I see a new test
> failure involving "RejectedExecutionException" being thrown:
>
> https://ge.apache.org/s/5ack462ji4mlu/tests/task/:solr:core:test/details/org.apac
Since the new multiThreaded search feature landed, I see a new test
failure involving "RejectedExecutionException" being thrown:
https://ge.apache.org/s/5ack462ji4mlu/tests/task/:solr:core:test/details/org.apache.solr.search.TestRealTimeGet/testStressGetRealtime?top-execution=1
It is thrown at a lo
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" --
While orthogonal, I'd rather we not write code that exists purely only
to solve this problem. Segment sizes are capped configurably in the
MergePolicy; you can lower it if the FixedBitSet would be too large
for the largest segments. For single-segment indexes (and the status
quo today), maybe the
Interesting -- although certainly related, I think these are somewhat
orthogonal questions. You could well have a merge strategy/heap and gc
configuration/index size that would have the same "humongous object"
problem even under a per-segment cache approach (certainly for cores
optimized to a singl
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
13 matches
Mail list logo
