I would prefer Lucene as a git submodule inside Solr. That way, I can work
with solr and Lucene together easily. The commit to which Lucene is pegged
at could be from a release branch or a tag.
On Sat, 27 Feb, 2021, 3:03 am Adrien Grand, wrote:
> FYI Elasticsearch has been regularly depending
FYI Elasticsearch has been regularly depending on builds of specific
commits of Lucene for this case of features that need changes both in
Lucene and Elasticsearch.
The workflow usually looks like this:
- Do work in Lucene.
- When it becomes clear that the next release of Lucene should happen
It does recurse indeed! To reuse Mike's example, in that case the cache
would consider caching:
- A,
- B,
- C,
- D,
- (C D),
- +A +B +(C D)
One weakness of this cache is that it doesn't consider caching subsets of
boolean queries (except single clauses). E.g. in the above example, it
would
Hi Haoyu,
I'm pretty sure (but not certain!) that query cache is smart enough to
recurse through the full query tree, and consider any of the whole queries
it finds during that recursion.
So e.g. a query like +A +B +(C D) would consider caching A, B, C D, or the
whole original +A +B +(C D)
Plus, isn’t this a reason for folks in the Solr side to continue to be involved
in the Lucene project? It’s the inverse of the days when folks wanted to cut
releases of Lucene, and were waiting for Solr to be ready!
> On Feb 26, 2021, at 1:26 PM, Houston Putman wrote:
>
> I don't think
I don't think Jan's workflow blocks Solr releases on Lucene releases. It
just blocks this one feature branch merge on a Lucene release. Multiple
Solr releases can happen between step 6 and step 7.
I completely agree with that being the workflow going forward with separate
repos, Jan. It will
The part of this process that I really don't like is that Solr then still
becomes beholden to Lucene's release schedule. We don't know how long step
7 takes, and will be effectively blocked from making our own releases until
that happens.
On Fri, Feb 26, 2021 at 8:51 AM Jan Høydahl wrote:
> The
I tried to debug this to the best of my ability, and it seems the correct name
for the “raw” evaluator is “val”.
Copied from StreamContext: val=class
org.apache.solr.client.solrj.io.eval.RawValueEvaluator
I think there’s a small error in stream evaluator documentation of 8.4
Maybe simply apply the standard in both places?
On Fri, Feb 26, 2021 at 9:04 AM Eric Pugh
wrote:
> I interpreted Mark as saying, we should forge ahead with the things like
> standardizing test names, and when the reference branch is ready, we tackle
> it.
>
> Having read most of the individual
The developer workflow for adding something to both Lucene and Solr would be as
any other dependency, right?
So say we are on Luene 9.0. This is the process in my head:
Adapt Lucene as needed, and "mvn install" lucene-9.1-SNAPSHOT to your local
laptop (whatever command that is in gradle)
Make
I interpreted Mark as saying, we should forge ahead with the things like
standardizing test names, and when the reference branch is ready, we tackle it.
Having read most of the individual commits, all 1405 and counting, I think that
bringing this code base in is going to be a major effort, and
Mark 2.0 speaks in riddles, which I'm not great at interpreting but I
think you're implying that the so-called "ref-branch" is not going to be
merged into anything, which is depressing because I now care much less
about that branch. Markus, Jason -- lets get the standardization on with!
~
> I hope that doesn’t sound too negative
Not to me. But I'm a little confused what your ultimate stand is on
these renames Marcus is proposing. I'm hearing different messages in
different sections of your email.
> There are already so many conflicts, you will cry and then realize there are
>
Except I just finished helping a contributor with a feature that touches
both and I know for a fact that it was developed for his customer who was
using solr (payload inequalities)... and have another in the works (the
AQP) Not being able to enhance lucene to support a feature in solr is
an
I hope that doesn’t sound too negative, “clinging” never sounds as positive
as I’d like and I do negative plenty well without doing it by accident. Not
a pessimistic statement though, I made it even better than I was planning
or remembering I could or however that works. Resistance is built into
There are already so many conflicts, you will cry and then realize there
are more. Even worse, some things have been changed due to their
cost/benefit failings, things that someone, somewhere, will cling to like a
life vest.
The ref branch waits for no man, and expects the same.
It lives on
I think we can start off with depending on lucene-SNAPSHOT in main branch. We
already have those, right?
https://repository.apache.org/#nexus-search;gav~org.apache.lucene~lucene-core~9.0.0-SNAPSHOT~~
If it becomes too flaky for Solr, we can push an internal 9.0-alpha-SNAPSHOT to
the nexus
17 matches
Mail list logo
