Is there some problem with our annotations that we hope to solve using
third party dependencies?
By the way, we have used Restlet in the past and that has been a
regrettable decision.
On Thu, Nov 25, 2021 at 10:10 AM Jason Gerlowski
wrote:
> Solr's custom annotation framework ('@Endpoint', '@Com
I've started a formal vote thread for the proposal here. Thanks all.
On Thu, Nov 25, 2021 at 12:10 PM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:
> We have closed the Google Doc for further comments, and all changes have
> been incorporated into the confluence document:
> https://cwi
Hi all,
SIP-15 for first class support of node roles has been proposed.
https://cwiki.apache.org/confluence/display/SOLR/SIP-15+Node+roles
The link contains two PDF files containing the discussion thread (since the
Pony mail thread links broke). The discussion happened in
dev@solr.apache.org list
We have closed the Google Doc for further comments, and all changes have
been incorporated into the confluence document:
https://cwiki.apache.org/confluence/display/SOLR/SIP-15+Node+roles
Thanks for all the comments and feedback.
On Thu, Nov 25, 2021 at 12:09 PM Ishan Chattopadhyaya <
ichattopadhy
> Maybe one way to provide for the future is to place some requirements on
roles, and designate that role-specific coordination information
> be placed within the subtree for that role under /node-roles//
To facilitate this we could
> 1. move the currently designed set of ephemeral nodes down one l
On Thu, Nov 25, 2021 at 4:35 AM Gus Heck wrote:
> Things I think still need to be clarified to define "Role" explicitly.
> Primarily to guide future implementations. Things I can think of include:
>
>- What the bar for something to be a role vs being more appropriate as
>a property/tag ty
On Thu, Nov 25, 2021 at 10:05 AM Gus Heck wrote:
> Things I think still need to be clarified to define "Role" explicitly.
> Primarily to guide future implementations. Things I can think of include:
>
>- What the bar for something to be a role vs being more appropriate as
>a property/tag t
On Thu, Nov 25, 2021 at 5:25 AM Jan Høydahl wrote:
> Very good points to clarify Gus.
>
> Also, as mentioned in Google Doc, I think the role framework should
> clarify the expectations for a node having a role.
> Does it mean that the node is eligible for - "MAY" - a certain
> feature/task, or do
Solr's custom annotation framework ('@Endpoint', '@Command', etc.) has
cropped up a few times over the past week or two. [1] [2]. Having them
on top of mind, I've been wondering - is there a reason we use our own
annotations here instead of something off the shelf?
What we have works well enough,
Hello everyone!
I started contributing to Solr(I am trying at least), and while I was
checking issues from JIRA to find something that I can solve, I found
https://issues.apache.org/jira/browse/SOLR-3128 this issue. First I tried
the issue on my local Solr and ShingleFilterFactory is doing its job
Very good points to clarify Gus.
Also, as mentioned in Google Doc, I think the role framework should clarify the
expectations for a node having a role.
Does it mean that the node is eligible for - "MAY" - a certain feature/task, or
does it mean that the node "MUST" execute that task.
I think "MA
Things I think still need to be clarified to define "Role" explicitly.
Primarily to guide future implementations. Things I can think of include:
- What the bar for something to be a role vs being more appropriate as a
property/tag type concept. Essentially what is and is not expected (at thi
On 11/24/21 1:08 PM, Thamizhazhagan B wrote:
When we give white space at the end, Solr gives random results. If we
remove the white space at the end, returns exact matching results.
For example:
*No whitespace at end:*
Keyword : “test result”
Result: This is *Test Result*
*Whitespace at the
> Moreover I think it's a very role specific notion, that is not a good
> fit in the roles framework, so maybe should never be part of this SIP.
Regarding "capable" vs "currently providing", I agree with Ilan here ^
On Wed, Nov 24, 2021 at 10:38 PM Gus Heck wrote:
> You do make a good point t
Hi,
When we give white space at the end, Solr gives random results. If we remove
the white space at the end, returns exact matching results.
For example:
No whitespace at end:
Keyword : "test result"
Result: This is Test Result
Whitespace at the end:
Keyword: "test result "
Result:
This is te
You do make a good point that the details can be very role specific. Maybe
one way to provide for the future is to place some requirements on roles,
and designate that role-specific coordination information be placed within
the subtree for that role under /node-roles// To facilitate this
we could
I agree with Ishan that "currently providing" shouldn't be a current
concern for the SIP.
Moreover I think it's a very role specific notion, that is not a good
fit in the roles framework, so maybe should never be part of this SIP.
Even on the Overseer example. Suppose we changed the current design
So we are potentially talking past each other. Let me re-clarify since
you've interpreted "configuration" differently (I think). What I'm
referring to in ZK is the "reflection of configuration" not the actual
configuration. This is why I'm asking the question of how much info should
be retained abo
On Wed, Nov 24, 2021 at 9:05 PM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:
>
>
> On Wed, Nov 24, 2021 at 8:19 PM Gus Heck wrote:
>
>> Left some additional comments in the google doc, extracting the key point
>> for others here so they can know if they want to read the google doc
>>
On Wed, Nov 24, 2021 at 8:19 PM Gus Heck wrote:
> Left some additional comments in the google doc, extracting the key point
> for others here so they can know if they want to read the google doc
> commentary:
>
I'm addressing them here, inline.
> There is presently disagreement with my proposa
Left some additional comments in the google doc, extracting the key point
for others here so they can know if they want to read the google doc
commentary:
There is presently disagreement with my proposal that the sip specify both
how we track configuration (which I have been referring to as "capab
I filed https://issues.apache.org/jira/browse/SOLR-15817 for this
Jan
> 19. nov. 2021 kl. 10:01 skrev Jan Høydahl :
>
> Sounds to me that, from solr 9.0, such things must also go into the official
> RM process. I have a proposal:
>
> Early on, right after cutting the branch, the RM files a blo
22 matches
Mail list logo
