Re: feature branches
Just another piece of gem that I know if is that if your feature branch name is in lowercase, commits there don't generate jira comments. On Wed, 20 Nov, 2019, 3:02 AM Michael Sokolov, wrote: > got it, thanks! > > On Tue, Nov 19, 2019 at 4:10 PM Dawid Weiss wrote: > > > > > Hoss said branches must be named starting jira/, but I'm not familiar > > > with this convention. > > > > This convention is merely so that when you do "git branch -r" the > > branches displayed are sorted and presented in some sane order > > (because of prefixes). > > > > > If we follow that, can we use github to coordinate PR's against a > feature branch among > > > multiple developers? > > > > If you create a branch with a prefix and somebody forks the project > > and then creates a pull request then it's still going to be against > > that prefixed branch (read: I don't see the problem?). > > > > Branches are just labels attached to a commit. Nothing special about > > the slash character (I believe). > > > > > > D. > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: Solr 8.3 Solrj streaming expressions do not return all field values
Ok, solved. Solr 8.2 accepted this statement: select(search(testcollection,q="test",df="Default",defType="edismax",fl="id", qt="/export", sort="id asc"),id,if(eq(1,1),Y,N) as found) and return to me the expected results. Note that around Y and N there is no ". Solr 8.3 requires the following statement select(search(testcollection,q="test",df="Default",defType="edismax",fl="id", qt="/export", sort="id asc"),id,if(eq(1,1),"Y","N") as found) to return the exact results. I do not know why I did originally not include the quotation marks around Y and N, but it seems that 8.2 accepted this and 8.3 not. I will update the Jira. On Tue, Nov 19, 2019 at 11:25 PM Jörn Franke wrote: > Could it be that Solr 8.3 is more strict on the if statement? > the statement if(eq(1,1),Y,N) > is supposed to return the character Y (not the field). In Solr 8.2 it > returns the character Y, but in Solr 8.3 not. > > On Tue, Nov 19, 2019 at 11:21 PM Jörn Franke wrote: > >> thanks i will find another installation of Solr, but last time the >> underlying queries to the export handler were correct. What was wrong was >> the generated field "found" based on the if statement based NOT on any data >> in the collectioj. As said, in Solr 8.3 the id fields are returned, but >> not the "found" field, which is generated by the selected statement: >> select(search(testcollection,q="test",df="Default",defType="edismax",fl= >> "id", qt="/export", sort="id asc"),id,if(eq(1,1),Y,N) as found) >> >> returns a tuple >> id: "blabla" >> >> but not the part generated by the if(eq(1,1),Y,N) as found. In Solr 8.2 >> the found field is returned: >> id: "blabla" >> found: "Y" >> To my best knowledge this is a fully generated field => it does not >> depend on the underlying collection data and the export handler. This was >> done to exclude any issues with this one. >> it states simply if 1=1 return Y else N >> >> >> On Fri, Nov 8, 2019 at 3:20 PM Joel Bernstein wrote: >> >>> Before moving to a jira let's take a look at the underlying Solr queries >>> in the log. The Streaming Expressions just creates solr queries, in this >>> case queries to the /export handler. So when something is not working as >>> expected we want to strip away the streaming expression and debug the >>> actual queries that are being run. >>> >>> You can find the Solr queries that appear in the log after running the >>> expressions and then try running them outside of the expression as plain >>> Solr queries. >>> >>> You can also post the Solr queries to this thread and we discuss what >>> the logs say. >>> >>> In these cases the logs always are the way to debug whats going on. >>> >>> >>> Joel Bernstein >>> http://joelsolr.blogspot.com/ >>> >>> >>> On Wed, Nov 6, 2019 at 4:14 PM Jörn Franke wrote: >>> I created a JIRA for this: https://issues.apache.org/jira/browse/SOLR-13894 On Wed, Nov 6, 2019 at 10:45 AM Jörn Franke wrote: > I have checked now Solr 8.3 server in admin UI. Same issue. > > Reproduction: > select(search(testcollection,q=“test”,df=“Default”,defType=“edismax”,fl=“id”, > qt=“/export”, sort=“id asc”),id,if(eq(1,1),Y,N) as found) > > In 8.3 it returns only the id field. > In 8.2 it returns id,found field. > > Since found is generated by select (and not coming from the > collection) there must be an issue with select. > > Any idea why this is happening. > > Debug logs do not show any error and the expression is correctly > received by Solr. > > Thank you. > > Best regards > > > Am 05.11.2019 um 14:59 schrieb Jörn Franke : > > > > Thanks I will check and come back to you. As far as I remember (but > have to check) the queries generated by Solr were correct > > > > Just to be clear the same thing works with Solr 8.2 server and Solr > 8.2 client. > > > > It show the odd behaviour with Solr 8.2 server and Solr 8.3 client. > > > >> Am 05.11.2019 um 14:49 schrieb Joel Bernstein : > >> > >> I'll probably need some more details. One thing that's useful is > to look at > >> the logs and see the underlying Solr queries that are generated. > Then try > >> those underlying queries against the Solr index and see what comes > back. If > >> you're not seeing the fields with the plain Solr queries then we > know it's > >> something going on below streaming expressions. If you are seeing > the > >> fields then it's the expressions themselves that are not handling > the data > >> as expected. > >> > >> > >> Joel Bernstein > >> http://joelsolr.blogspot.com/ > >> > >> > On Mon, Nov 4, 2019 at 9:09 AM Jörn Franke > wrote: > >>> > >>> Most likely this issue can bei also reproduced in the admin UI for > the > >>> streaming handler of a collection. > >>> > > Am 04.11.2019 um 13:32 schrieb Jörn Franke >: >
Re: Solr 8.3 Solrj streaming expressions do not return all field values
Could it be that Solr 8.3 is more strict on the if statement?
the statement if(eq(1,1),Y,N)
is supposed to return the character Y (not the field). In Solr 8.2 it
returns the character Y, but in Solr 8.3 not.
On Tue, Nov 19, 2019 at 11:21 PM Jörn Franke wrote:
> thanks i will find another installation of Solr, but last time the
> underlying queries to the export handler were correct. What was wrong was
> the generated field "found" based on the if statement based NOT on any data
> in the collectioj. As said, in Solr 8.3 the id fields are returned, but
> not the "found" field, which is generated by the selected statement:
> select(search(testcollection,q="test",df="Default",defType="edismax",fl=
> "id", qt="/export", sort="id asc"),id,if(eq(1,1),Y,N) as found)
>
> returns a tuple
> id: "blabla"
>
> but not the part generated by the if(eq(1,1),Y,N) as found. In Solr 8.2
> the found field is returned:
> id: "blabla"
> found: "Y"
> To my best knowledge this is a fully generated field => it does not depend
> on the underlying collection data and the export handler. This was done to
> exclude any issues with this one.
> it states simply if 1=1 return Y else N
>
>
> On Fri, Nov 8, 2019 at 3:20 PM Joel Bernstein wrote:
>
>> Before moving to a jira let's take a look at the underlying Solr queries
>> in the log. The Streaming Expressions just creates solr queries, in this
>> case queries to the /export handler. So when something is not working as
>> expected we want to strip away the streaming expression and debug the
>> actual queries that are being run.
>>
>> You can find the Solr queries that appear in the log after running the
>> expressions and then try running them outside of the expression as plain
>> Solr queries.
>>
>> You can also post the Solr queries to this thread and we discuss what the
>> logs say.
>>
>> In these cases the logs always are the way to debug whats going on.
>>
>>
>> Joel Bernstein
>> http://joelsolr.blogspot.com/
>>
>>
>> On Wed, Nov 6, 2019 at 4:14 PM Jörn Franke wrote:
>>
>>> I created a JIRA for this:
>>> https://issues.apache.org/jira/browse/SOLR-13894
>>>
>>> On Wed, Nov 6, 2019 at 10:45 AM Jörn Franke
>>> wrote:
>>>
I have checked now Solr 8.3 server in admin UI. Same issue.
Reproduction:
select(search(testcollection,q=“test”,df=“Default”,defType=“edismax”,fl=“id”,
qt=“/export”, sort=“id asc”),id,if(eq(1,1),Y,N) as found)
In 8.3 it returns only the id field.
In 8.2 it returns id,found field.
Since found is generated by select (and not coming from the collection)
there must be an issue with select.
Any idea why this is happening.
Debug logs do not show any error and the expression is correctly
received by Solr.
Thank you.
Best regards
> Am 05.11.2019 um 14:59 schrieb Jörn Franke :
>
> Thanks I will check and come back to you. As far as I remember (but
have to check) the queries generated by Solr were correct
>
> Just to be clear the same thing works with Solr 8.2 server and Solr
8.2 client.
>
> It show the odd behaviour with Solr 8.2 server and Solr 8.3 client.
>
>> Am 05.11.2019 um 14:49 schrieb Joel Bernstein :
>>
>> I'll probably need some more details. One thing that's useful is to
look at
>> the logs and see the underlying Solr queries that are generated.
Then try
>> those underlying queries against the Solr index and see what comes
back. If
>> you're not seeing the fields with the plain Solr queries then we
know it's
>> something going on below streaming expressions. If you are seeing the
>> fields then it's the expressions themselves that are not handling
the data
>> as expected.
>>
>>
>> Joel Bernstein
>> http://joelsolr.blogspot.com/
>>
>>
On Mon, Nov 4, 2019 at 9:09 AM Jörn Franke
wrote:
>>>
>>> Most likely this issue can bei also reproduced in the admin UI for
the
>>> streaming handler of a collection.
>>>
> Am 04.11.2019 um 13:32 schrieb Jörn Franke >>> >:
Hi,
I use streaming expressions, e.g.
Sort(Select(search(...),id,if(eq(1,1),Y,N) as found), by=“field A
asc”)
(Using export handler, sort is not really mandatory , I will
remove it
>>> later anyway)
This works perfectly fine if I use Solr 8.2.0 (server + client). It
>>> returns Tuples in the form { “id”,”12345”, “found”:”Y”}
However, if I use Solr 8.2.0 as server and Solr 8.3.0 as client
then the
>>> above statement only returns the id field, but not the found field.
Questions:
1) is this expected behavior, ie Solr client 8.3.0 is in this case
not
>>> compatible with Solr 8.2.0 and server upgrade to Solr 8.3.0 will
fix this?
2)
Re: Solr 8.3 Solrj streaming expressions do not return all field values
thanks i will find another installation of Solr, but last time the
underlying queries to the export handler were correct. What was wrong was
the generated field "found" based on the if statement based NOT on any data
in the collectioj. As said, in Solr 8.3 the id fields are returned, but
not the "found" field, which is generated by the selected statement:
select(search(testcollection,q="test",df="Default",defType="edismax",fl="id",
qt="/export", sort="id asc"),id,if(eq(1,1),Y,N) as found)
returns a tuple
id: "blabla"
but not the part generated by the if(eq(1,1),Y,N) as found. In Solr 8.2 the
found field is returned:
id: "blabla"
found: "Y"
To my best knowledge this is a fully generated field => it does not depend
on the underlying collection data and the export handler. This was done to
exclude any issues with this one.
it states simply if 1=1 return Y else N
On Fri, Nov 8, 2019 at 3:20 PM Joel Bernstein wrote:
> Before moving to a jira let's take a look at the underlying Solr queries
> in the log. The Streaming Expressions just creates solr queries, in this
> case queries to the /export handler. So when something is not working as
> expected we want to strip away the streaming expression and debug the
> actual queries that are being run.
>
> You can find the Solr queries that appear in the log after running the
> expressions and then try running them outside of the expression as plain
> Solr queries.
>
> You can also post the Solr queries to this thread and we discuss what the
> logs say.
>
> In these cases the logs always are the way to debug whats going on.
>
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
>
> On Wed, Nov 6, 2019 at 4:14 PM Jörn Franke wrote:
>
>> I created a JIRA for this:
>> https://issues.apache.org/jira/browse/SOLR-13894
>>
>> On Wed, Nov 6, 2019 at 10:45 AM Jörn Franke wrote:
>>
>>> I have checked now Solr 8.3 server in admin UI. Same issue.
>>>
>>> Reproduction:
>>> select(search(testcollection,q=“test”,df=“Default”,defType=“edismax”,fl=“id”,
>>> qt=“/export”, sort=“id asc”),id,if(eq(1,1),Y,N) as found)
>>>
>>> In 8.3 it returns only the id field.
>>> In 8.2 it returns id,found field.
>>>
>>> Since found is generated by select (and not coming from the collection)
>>> there must be an issue with select.
>>>
>>> Any idea why this is happening.
>>>
>>> Debug logs do not show any error and the expression is correctly
>>> received by Solr.
>>>
>>> Thank you.
>>>
>>> Best regards
>>>
>>> > Am 05.11.2019 um 14:59 schrieb Jörn Franke :
>>> >
>>> > Thanks I will check and come back to you. As far as I remember (but
>>> have to check) the queries generated by Solr were correct
>>> >
>>> > Just to be clear the same thing works with Solr 8.2 server and Solr
>>> 8.2 client.
>>> >
>>> > It show the odd behaviour with Solr 8.2 server and Solr 8.3 client.
>>> >
>>> >> Am 05.11.2019 um 14:49 schrieb Joel Bernstein :
>>> >>
>>> >> I'll probably need some more details. One thing that's useful is to
>>> look at
>>> >> the logs and see the underlying Solr queries that are generated. Then
>>> try
>>> >> those underlying queries against the Solr index and see what comes
>>> back. If
>>> >> you're not seeing the fields with the plain Solr queries then we know
>>> it's
>>> >> something going on below streaming expressions. If you are seeing the
>>> >> fields then it's the expressions themselves that are not handling the
>>> data
>>> >> as expected.
>>> >>
>>> >>
>>> >> Joel Bernstein
>>> >> http://joelsolr.blogspot.com/
>>> >>
>>> >>
>>> On Mon, Nov 4, 2019 at 9:09 AM Jörn Franke
>>> wrote:
>>> >>>
>>> >>> Most likely this issue can bei also reproduced in the admin UI for
>>> the
>>> >>> streaming handler of a collection.
>>> >>>
>>> > Am 04.11.2019 um 13:32 schrieb Jörn Franke :
>>>
>>> Hi,
>>>
>>> I use streaming expressions, e.g.
>>> Sort(Select(search(...),id,if(eq(1,1),Y,N) as found), by=“field A
>>> asc”)
>>> (Using export handler, sort is not really mandatory , I will remove
>>> it
>>> >>> later anyway)
>>>
>>> This works perfectly fine if I use Solr 8.2.0 (server + client). It
>>> >>> returns Tuples in the form { “id”,”12345”, “found”:”Y”}
>>>
>>> However, if I use Solr 8.2.0 as server and Solr 8.3.0 as client
>>> then the
>>> >>> above statement only returns the id field, but not the found field.
>>>
>>> Questions:
>>> 1) is this expected behavior, ie Solr client 8.3.0 is in this case
>>> not
>>> >>> compatible with Solr 8.2.0 and server upgrade to Solr 8.3.0 will fix
>>> this?
>>> 2) has the syntax for the above expression changed? If so how?
>>> 3) is this not expected behavior and I should create a Jira for it?
>>>
>>> Thank you.
>>> Best regards
>>> >>>
>>>
>>
Re: Welcome Houston Putman as Lucene/Solr committer
Welcome Houston, Looking forward to working with you On Tue, Nov 19, 2019 at 12:58 AM Martin Gainty wrote: > > welcome Houston! > martin- > > From: Michael McCandless > Sent: Sunday, November 17, 2019 10:32 AM > To: dev@lucene.apache.org > Cc: Houston Putman > Subject: Re: Welcome Houston Putman as Lucene/Solr committer > > Welcome Houston! > > Mike > > On Thu, Nov 14, 2019 at 3:58 AM Anshum Gupta wrote: > > Hi all, > > Please join me in welcoming Houston Putman as the latest Lucene/Solr > committer! > > Houston has been involved with the community since 2013, when he first > contributed the Analytics contrib module. Since then he has been involved > with the community, participated in conferences and spoken about his work > with Lucene/Solr. In the recent past, he has been involved with getting Solr > to scale on Kubernetes. > > Looking forward to your commits to the Apache Lucene/Solr project :) > > Congratulations and welcome, Houston! It's a tradition to introduce yourself > with a brief bio. > > -- > Anshum Gupta > > -- > Mike McCandless > > http://blog.mikemccandless.com -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: feature branches
got it, thanks! On Tue, Nov 19, 2019 at 4:10 PM Dawid Weiss wrote: > > > Hoss said branches must be named starting jira/, but I'm not familiar > > with this convention. > > This convention is merely so that when you do "git branch -r" the > branches displayed are sorted and presented in some sane order > (because of prefixes). > > > If we follow that, can we use github to coordinate PR's against a feature > > branch among > > multiple developers? > > If you create a branch with a prefix and somebody forks the project > and then creates a pull request then it's still going to be against > that prefixed branch (read: I don't see the problem?). > > Branches are just labels attached to a commit. Nothing special about > the slash character (I believe). > > > D. > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: feature branches
> Hoss said branches must be named starting jira/, but I'm not familiar > with this convention. This convention is merely so that when you do "git branch -r" the branches displayed are sorted and presented in some sane order (because of prefixes). > If we follow that, can we use github to coordinate PR's against a feature > branch among > multiple developers? If you create a branch with a prefix and somebody forks the project and then creates a pull request then it's still going to be against that prefixed branch (read: I don't see the problem?). Branches are just labels attached to a commit. Nothing special about the slash character (I believe). D. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
feature branches
Hi, can someone point me to how-to for feature branches? Recently, Hoss said branches must be named starting jira/, but I'm not familiar with this convention. Is it written down somewhere? If we follow that, can we use github to coordinate PR's against a feature branch among multiple developers? -Mike - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: BadApple
> it's already been addressed - by you - in LUCENE-8920 (Erick's note was about it's overall success rate for the past 7 days) Yeah, thanks. Brain caught up with hands and I realized that must be it shortly after posting. On Tue, Nov 19, 2019 at 1:33 AM Ishan Chattopadhyaya wrote: > > Thanks Erick. I've fixed the package manager tests. > > On Mon, 18 Nov, 2019, 9:58 PM Erick Erickson, wrote: >> >> Short form: >> >> Holding reasonably steady, except: >> >> PackageManagerCLITest.testPackeageManager is failing over 50% of the time. >> >> MoverReplicaHDFSTest.test failing over 40% of the time. >> >> TestFstDirectAddressing.testDeDupeTails is failing 18% of the time. >> >> Full output attached: >> >> >> There were 154 unannotated tests that failed in Hoss' rollups. Ordered by >> the date I downloaded the rollup file, newest->oldest. See above for the >> dates the files were collected >> These tests were NOT BadApple'd or AwaitsFix'd >> All tests that failed 4 weeks running will be BadApple'd unless there are >> objections >> >> Failures in the last 4 reports.. >>Report Pct runsfails test >> 0123 3.3 917 45 BasicAuthIntegrationTest.testBasicAuth >> 0123 0.5 943 7 >> DimensionalRoutedAliasUpdateProcessorTest.testCatTime >> 0123 2.7 943 18 >> DimensionalRoutedAliasUpdateProcessorTest.testTimeCat >> 0123 8.3 961 91 >> LegacyCloudClusterPropTest.testCreateCollectionSwitchLegacyCloud >> 0123 43.8 202 85 MoveReplicaHDFSTest.test >> 0123 0.5 903 5 >> ReindexCollectionTest.testSameTargetReindexing >> 0123 4.8 104 5 ShardSplitTest.testSplitWithChaosMonkey >> 0123 0.5 918 9 >> SystemCollectionCompatTest.testBackCompat >> 0123 4.8 941 52 >> TestCloudSearcherWarming.testRepFactor1LeaderStartup >> 0123 2.7 946 77 >> TestModelManagerPersistence.testFilePersistence >> 0123 2.2 940 70 >> TestModelManagerPersistence.testWrapperModelPersistence >> 0123 1.6 921 19 >> TestSkipOverseerOperations.testSkipLeaderOperations >> 0123 0.6 905 11 TestStressLiveNodes.testStress >> 0123 1.1 651 9 TestTlogReplica.testKillTlogReplica >> 0123 4.2 112 11 >> TestXYMultiPolygonShapeQueries.testRandomBig >> Will BadApple all tests above this line except ones listed at >> the top** >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
