On 6/17/22 18:21, Noble Paul wrote:
Is there a need to make it easier to invoke POST/PUT/DELETE methods ?
absolutely yes.
But, that should be a separate effort. Most likely , we would keep the
V1 API around for a while and users could resort to those APIs if they
wish to. However, the discus
@Shawn
Is there a need to make it easier to invoke POST/PUT/DELETE methods ?
absolutely yes.
But, that should be a separate effort. Most likely , we would keep the V1
API around for a while and users could resort to those APIs if they wish
to. However, the discussion is around whether we should m
I really appreciate the perspective you bring Shawn on helping users...
we should think about how to make it easy for a user to run a command...
maybe an explicit admin UI for running arbitrary commands int he same way
we use the browser???
On Fri, Jun 17, 2022 at 1:35 PM Shawn Heisey wrote:
> O
It's been >72h since the vote was initiated and the result is:
+1 6 (6 binding)
0 1
-1 0
This vote has PASSED
On Mon, Jun 13, 2022 at 12:05 PM Mike Drob wrote:
> Please vote for release candidate 2 for Lucene/Solr 8.11.2
>
> The artifacts can be downloaded from:
>
> https://dist.apache.or
On 6/17/2022 12:15 PM, Jason Gerlowski wrote:
Hey Shawn, Gus: I agree that "just sharing a URL" is dead simple and
can help for less-sophisticated users, or in more locked-down (i.e.
dev tool-less) environments. But I agree with Noble's point: using
the full range of HTTP methods is about as uni
I was sanity checking some stuff about how we deal with '_version_'
tracking (per shard) and noticed that VersionInfo.updateClock is not
called anywhere in the code base...
public void updateClock(long clock) {
synchronized (clockSync) {
vclock = Math.max(vclock, clock);
}
Thanks Uwe, jira filed...
https://issues.apache.org/jira/browse/SOLR-16258
: Date: Thu, 9 Jun 2022 10:52:03 +0200
: From: Uwe Schindler
: Reply-To: dev@solr.apache.org
: To: dev@solr.apache.org
: Subject: Re: Obscenely long gradle compile times? (related to error-prone
: plugin?)
:
: Hi
Hey all,
Thanks for the quick responses! Overall it sounds like no one objects
to the idea of broader changes necessarily, but that there are some
concerns about the timing/mechanics (backcompat, target release, etc.)
and specific API design (use of HTTP verbs, "URL-bar" friendliness,
etc). Hope
