Re: Edismax parsing when using pf parameter

[Pierre Salagnac]

I opened a pull request[1] that fixes the case reported. The issue was
subqueries with grouped fields like "field:(term1 term2 term3), only the
first term was skipped when generating the boost query with fields
specified in pf parameter.

Unfortunately, this pre-parsing (method splitIntoClauses()) of edismax
parser and how we handle its results to generate the boost query is still
questionable. For example, for the query "term1 field:(term2 term3) term4"
we may still generate a boost query "term1 term4". Not sure whether it is
relevant or not. There is probably no definitive answer to this question.

I appreciate any feedback on the change
Best
Pierre

[1] https://github.com/apache/solr/pull/1893

Le mar. 29 août 2023 à 09:52, Mónica Marrero 
a écrit :

> Thank you, Chris. Here is the JIRA ticket:
> https://issues.apache.org/jira/browse/SOLR-16953
>
> Best,
>
> Mónica
>
> --
> Disclaimer: This email and any files transmitted with it are confidential
> and intended solely for the use of the individual or entity to whom they
> are
> addressed. If you have received this email in error please notify the
> system manager. If you are not the named addressee you should not
> disseminate,
> distribute or copy this email. Please notify the sender
> immediately by email if you have received this email by mistake and delete
> this email from your
> system.
>

Re: Reg CVE 2021-44832

[Shawn Heisey]

On 9/5/23 23:10, ramkrishna vasudevan wrote:

Clearly says this vulnerability is not affected in 7.4 to 8.11.1 but the
affected components are 'log4j-core-2.14.1.jar, log4j-core-2.16.0.jar'.

So does that mean that if we are with log4j-core-2.17.0.jar then this
vulnerability needs to be fixed? Or the same argument that '*Solr's default
log configuration doesn't use JDBCAppender and we don't imagine a user
would want to use it or other obscure appenders*.'  is it valid for 2.17.0
version also?


You can only be affected if you have changed the logging config in your 
Solr install to use JDBCAppender.  Solr's default logging config does 
NOT use that appender.


You could upgrade all the log4j jars in Solr to 2.17.2 and then your 
vulnerability scanner should not find that vulnerability.


It MIGHT be safe to update the log4j jars to 2.20.0, the latest release, 
but I can't guarantee that.  Updating to 2.17.2 would be safe.  I have 
done that without problems.


Thanks,
Shawn


-
To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
For additional commands, e-mail: dev-h...@solr.apache.org

Build: checkWorkingCopyClean -- is there value?

[David Smiley]

Our build, inherited from Lucene, contains a custom validation check
"checkWorkingCopyClean" which can be disabled with
"validation.git.failOnModified=false" in your gradle.properties.  I always
set this; the concept of failOnModifies seems dubious to me; it annoys me.
Can an advocate of this setting speak up and tell me why it's useful?

~ David

Re: Build: checkWorkingCopyClean -- is there value?

[Uwe Schindler]

The idea is that jenkins runs it after the builds to figure out if 
something changed in the working copy. At ANT times this was implemented 
exactly like this, we failed build on Jenkins when the working copy 
changed. This was especially important before we used SecurityManager to 
prevent tests writing outside their temporary dirs. We had tests 
touching files in working copy.


We had a discussion about this task with Dawid Weiss when changing to 
Gradle, but I don't remeber the outcome. To me the default should be 
false. I think Dawid argued that the check is good to notify the 
committer that there may be uncommitted changes, but I doubt this helps. 
A warning would be fine.


Uwe

Am 06.09.2023 um 18:43 schrieb David Smiley:

Our build, inherited from Lucene, contains a custom validation check
"checkWorkingCopyClean" which can be disabled with
"validation.git.failOnModified=false" in your gradle.properties.  I always
set this; the concept of failOnModifies seems dubious to me; it annoys me.
Can an advocate of this setting speak up and tell me why it's useful?

~ David


--
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail: u...@thetaphi.de


-
To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
For additional commands, e-mail: dev-h...@solr.apache.org

Re: Build: checkWorkingCopyClean -- is there value?

[Jason Gerlowski]

+1 to flipping the default for 'failOnModified'.

On Wed, Sep 6, 2023 at 3:21 PM Uwe Schindler  wrote:
>
> The idea is that jenkins runs it after the builds to figure out if
> something changed in the working copy. At ANT times this was implemented
> exactly like this, we failed build on Jenkins when the working copy
> changed. This was especially important before we used SecurityManager to
> prevent tests writing outside their temporary dirs. We had tests
> touching files in working copy.
>
> We had a discussion about this task with Dawid Weiss when changing to
> Gradle, but I don't remeber the outcome. To me the default should be
> false. I think Dawid argued that the check is good to notify the
> committer that there may be uncommitted changes, but I doubt this helps.
> A warning would be fine.
>
> Uwe
>
> Am 06.09.2023 um 18:43 schrieb David Smiley:
> > Our build, inherited from Lucene, contains a custom validation check
> > "checkWorkingCopyClean" which can be disabled with
> > "validation.git.failOnModified=false" in your gradle.properties.  I always
> > set this; the concept of failOnModifies seems dubious to me; it annoys me.
> > Can an advocate of this setting speak up and tell me why it's useful?
> >
> > ~ David
> >
> --
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> For additional commands, e-mail: dev-h...@solr.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
For additional commands, e-mail: dev-h...@solr.apache.org

Re: Build: checkWorkingCopyClean -- is there value?

[Shawn Heisey]

On 9/6/23 10:43, David Smiley wrote:

Our build, inherited from Lucene, contains a custom validation check
"checkWorkingCopyClean" which can be disabled with
"validation.git.failOnModified=false" in your gradle.properties.  I always
set this; the concept of failOnModifies seems dubious to me; it annoys me.
Can an advocate of this setting speak up and tell me why it's useful?


I get hit by that pretty much every time I run the check target.  I 
don't think it fills any useful role ... 99 percent of the time the 
check target is executed, I am pretty sure that the checkout won't be 
clean.  I wouldn't mind a warning logged at the end of the run that says 
the working tree isn't clean, but I really hate that it makes the check 
fail.


Thanks,
Shawn


-
To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
For additional commands, e-mail: dev-h...@solr.apache.org

Re: Build: checkWorkingCopyClean -- is there value?

[Shawn Heisey]

On 9/6/23 13:21, Uwe Schindler wrote:
The idea is that jenkins runs it after the builds to figure out if 
something changed in the working copy. At ANT times this was implemented 
exactly like this, we failed build on Jenkins when the working copy 
changed. This was especially important before we used SecurityManager to 
prevent tests writing outside their temporary dirs. We had tests 
touching files in working copy.


That makes sense, and for Jenkins it sounds like a very good idea.  I 
think that Jenkins should probably explicitly request that check ... 
having it enabled by default for everyone is not the best idea IMHO.


Thanks,
Shawn


-
To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
For additional commands, e-mail: dev-h...@solr.apache.org

Re: Build: checkWorkingCopyClean -- is there value?

[Eric Pugh]

It’s bit me plenty of times as well….   I like the idea of it not being enabled 
by default.

> On Sep 6, 2023, at 4:49 PM, Shawn Heisey  wrote:
> 
> On 9/6/23 13:21, Uwe Schindler wrote:
>> The idea is that jenkins runs it after the builds to figure out if something 
>> changed in the working copy. At ANT times this was implemented exactly like 
>> this, we failed build on Jenkins when the working copy changed. This was 
>> especially important before we used SecurityManager to prevent tests writing 
>> outside their temporary dirs. We had tests touching files in working copy.
> 
> That makes sense, and for Jenkins it sounds like a very good idea.  I think 
> that Jenkins should probably explicitly request that check ... having it 
> enabled by default for everyone is not the best idea IMHO.
> 
> Thanks,
> Shawn
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> For additional commands, e-mail: dev-h...@solr.apache.org
> 

___
Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
http://www.opensourceconnections.com  | 
My Free/Busy   
Co-Author: Apache Solr Enterprise Search Server, 3rd Ed 


This e-mail and all contents, including attachments, is considered to be 
Company Confidential unless explicitly stated otherwise, regardless of whether 
attachments are marked as such.

Re: Build: checkWorkingCopyClean -- is there value?

[David Smiley]

Is there a property or something used to detect that the build is being run
in a CI or CI-like env?
~ David


On Wed, Sep 6, 2023 at 4:50 PM Shawn Heisey  wrote:

> On 9/6/23 13:21, Uwe Schindler wrote:
> > The idea is that jenkins runs it after the builds to figure out if
> > something changed in the working copy. At ANT times this was implemented
> > exactly like this, we failed build on Jenkins when the working copy
> > changed. This was especially important before we used SecurityManager to
> > prevent tests writing outside their temporary dirs. We had tests
> > touching files in working copy.
>
> That makes sense, and for Jenkins it sounds like a very good idea.  I
> think that Jenkins should probably explicitly request that check ...
> having it enabled by default for everyone is not the best idea IMHO.
>
> Thanks,
> Shawn
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> For additional commands, e-mail: dev-h...@solr.apache.org
>
>

Re: Discuss SIP-14 Embedded Zookeeper

[Jan Høydahl]

Hi,

Eric Pugh and I discussed this SIP the other day, as a stepping stone for 
making cloud mode the default. Perhaps there is new energy for this two years 
down the road? 

We don't need to tackle the full dynamic scaling of ZK on day one.
Just adding a 'zookeeper' node-role so we could have tree fixed nodes acting as 
ZK would be a win and lower the complexity of deploying Solr.
We could always add magic auto scaling later.

Jan

> 17. jan. 2022 kl. 06:57 skrev Mark Miller :
> 
> Yeah, there two reasons we didn’t push embedded Zookeeper out of the gate and 
> even went so far as to call it a non production “demo” feature.  Dynamic 
> reconfiguration as a cluster changed over time, and a Zookeeper instance per 
> Solr node being prohibitive. At least the latter was theoretical externally 
> solvable it felt, but at the time, that just brought back around to the lack 
> of dynamic configuration.


-
To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
For additional commands, e-mail: dev-h...@solr.apache.org

Re: Build: checkWorkingCopyClean -- is there value?

[Michael Gibney]

Something like this could work?:

https://github.com/apache/solr/blob/eaaabbfa33456639613a7a6aecc37cd2d89e5dfa/gradle/globals.gradle#L168-L171

On Wed, Sep 6, 2023 at 5:26 PM David Smiley  wrote:
>
> Is there a property or something used to detect that the build is being run
> in a CI or CI-like env?
> ~ David
>
>
> On Wed, Sep 6, 2023 at 4:50 PM Shawn Heisey  wrote:
>
> > On 9/6/23 13:21, Uwe Schindler wrote:
> > > The idea is that jenkins runs it after the builds to figure out if
> > > something changed in the working copy. At ANT times this was implemented
> > > exactly like this, we failed build on Jenkins when the working copy
> > > changed. This was especially important before we used SecurityManager to
> > > prevent tests writing outside their temporary dirs. We had tests
> > > touching files in working copy.
> >
> > That makes sense, and for Jenkins it sounds like a very good idea.  I
> > think that Jenkins should probably explicitly request that check ...
> > having it enabled by default for everyone is not the best idea IMHO.
> >
> > Thanks,
> > Shawn
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> > For additional commands, e-mail: dev-h...@solr.apache.org
> >
> >

-
To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
For additional commands, e-mail: dev-h...@solr.apache.org

Re: Build: checkWorkingCopyClean -- is there value?

[David Smiley]

Honestly, I would prefer to do away with it entirely.  Dubious logic that
has been made to only output a warning will continue to be a part of the
code weight of our sprawling build.  It will need to be maintained[1].  It
needs to do it's calculations on every check/precommit.  I don't even want
to be "warned" about the fact that I am modifying files.  *Of course* there
are modified files; I am actually work on this codebase!

[1] even making it have a computed default is an example of this
maintenance cost!

~ David


On Wed, Sep 6, 2023 at 8:46 PM Michael Gibney 
wrote:

> Something like this could work?:
>
>
> https://github.com/apache/solr/blob/eaaabbfa33456639613a7a6aecc37cd2d89e5dfa/gradle/globals.gradle#L168-L171
>
> On Wed, Sep 6, 2023 at 5:26 PM David Smiley 
> wrote:
> >
> > Is there a property or something used to detect that the build is being
> run
> > in a CI or CI-like env?
> > ~ David
> >
> >
> > On Wed, Sep 6, 2023 at 4:50 PM Shawn Heisey  wrote:
> >
> > > On 9/6/23 13:21, Uwe Schindler wrote:
> > > > The idea is that jenkins runs it after the builds to figure out if
> > > > something changed in the working copy. At ANT times this was
> implemented
> > > > exactly like this, we failed build on Jenkins when the working copy
> > > > changed. This was especially important before we used
> SecurityManager to
> > > > prevent tests writing outside their temporary dirs. We had tests
> > > > touching files in working copy.
> > >
> > > That makes sense, and for Jenkins it sounds like a very good idea.  I
> > > think that Jenkins should probably explicitly request that check ...
> > > having it enabled by default for everyone is not the best idea IMHO.
> > >
> > > Thanks,
> > > Shawn
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> > > For additional commands, e-mail: dev-h...@solr.apache.org
> > >
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> For additional commands, e-mail: dev-h...@solr.apache.org
>
>