Right; it should aim to read naturally as if in English, that's the idea.
We can *prefer* the "with" prefix but some parameters might be expressed
more clearly in some other way, especially if boolean. In
CloudHttp2SolrClient, I see one "sendDirectUpdatesToShardLeadersOnly()"
which I think is
Hi David,
Thanks for bringing the PR up for attention here. Had a few thoughts on
the setter and build() naming, as you called out, and commented on those in
the PR. But otherwise, it looks very nice so far!
Best,
Jason
On Tue, Jan 3, 2023 at 1:06 AM David Smiley wrote:
> Happy New Year
I vote for the "with" option. Seems to be the most common builder pattern.
- Houston
On Thu, Dec 29, 2022 at 7:41 AM Eric Pugh
wrote:
> Hi all,
>
> I wanted to drop a note and ask if there were any standards/patterns that
> we use in Solr (or want to use!) for naming methods for builders?
>
>
On 1/3/23 08:05, Michael Gibney wrote:
and possibly upgrade to Lucene 9.4
https://issues.apache.org/jira/browse/SOLR-16442
particularly considering:
https://github.com/apache/lucene/pull/11718
It seems like a bad idea to upgrade a critical component to a new major
or minor version in a bugfix
Thanks! Agreed wrt 9.2 soon w/ Lucene upgrade; but to be explicit: the
SlotAcc deadlock in particular can be addressed in 9.1.1 (by
backporting SOLR-16165). The analyzer SPI deadlock (requires Lucene
9.4) is separate.
On Tue, Jan 3, 2023 at 11:02 AM Ishan Chattopadhyaya
wrote:
>
> The slot
Thanks for catching the reason here Kevin!
Was just starting to investigate these.
On Tue, Jan 3, 2023 at 10:52 AM Kevin Risden wrote:
> JDK 20 Build 21 added new locales - https://jdk.java.net/20/release-notes
>
> specifically through https://cldr.unicode.org/index/downloads/cldr-42
>
> These
The slot accumulator deadlocks make a good case for doing a 9.2 soon
(with the Lucene upgrade).
On Tue, Jan 3, 2023 at 9:30 PM Ishan Chattopadhyaya
wrote:
>
> +1 to SOLR-16165.
> Let's not do a Lucene upgrade in a bugfix release.
>
> I have some pending steps from the post release of 9.1, I'll
+1 to SOLR-16165.
Let's not do a Lucene upgrade in a bugfix release.
I have some pending steps from the post release of 9.1, I'll complete
them in another 48-72 hours. Sorry about the delay.
On Tue, Jan 3, 2023 at 9:16 PM David Smiley wrote:
>
> +1. Don't add a Lucene upgrade though :-)
>
> ~
JDK 20 Build 21 added new locales - https://jdk.java.net/20/release-notes
specifically through https://cldr.unicode.org/index/downloads/cldr-42
These locales (raj, bho, bgc) need to added to
+1. Don't add a Lucene upgrade though :-)
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Tue, Jan 3, 2023 at 10:05 AM Michael Gibney
wrote:
> Wondering what folks think of backporting some classloading
> deadlock-related fixes:
>
Wondering what folks think of backporting some classloading
deadlock-related fixes:
https://issues.apache.org/jira/browse/SOLR-16165
and possibly upgrade to Lucene 9.4
https://issues.apache.org/jira/browse/SOLR-16442
particularly considering:
https://github.com/apache/lucene/pull/11718
The main
On 1/3/23 02:53, Bram Van Dam wrote:
For a bit more context: we noticed that without docValues, the unique
key field ends up wasting gigabytes of memory per core (in field cache,
iirc). One entry per unique identifier. Regardless of whether or not the
core is even being hit. With docValues
On 03/01/2023 03.54, Shawn Heisey wrote:
Some features like grouping appear to require docValues to work at all.
If some shards have docValues and some don't, those features are likely
to break horribly, or at least not return expected results.
You're probably right in saying that this will
We should rather work towards better documentation and perhaps tooling on what
schema updates are "safe" without reindexing. It is NOT safe to change a
field's type (or add docValues in-flight). Would be nice if the user is alerted
about this when deploying the new schema. Masking the issue by
14 matches
Mail list logo
