[
https://issues.apache.org/jira/browse/SOLR-16681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17695871#comment-17695871
]
Mikhail Khludnev edited comment on SOLR-16681 at 3/2/23 8:05 PM:
-----------------------------------------------------------------
I think [https://github.com/apache/solr/pull/1384] is ready.
Remaining doubts are:
* is it fine to piggyback on those tests or it's worth to bring up a new one?
* I'm sure there's a better wording in exception message. Which one?
* I feel like it's really hard to explain in documentation especially giving
that it's something which doesn't work. I think exception is explicit enough.
I wish put it into 9.2 as is.
was (Author: mkhludnev):
I think like [https://github.com/apache/solr/pull/1384]
Remaining doubts are:
* is it fine to piggyback on those tests or it's worth to bring up a new one?
* I'm sure there's a better wording in exception message. Which one?
* I feel like it's really hard to explain in documentation especially giving
that it's something which doesn't work. I think exception is explicit enough.
I wish put it into 9.2 as is.
> Replacing uniqueKey field via fl doesn't work in distributed since 9.0
> ----------------------------------------------------------------------
>
> Key: SOLR-16681
> URL: https://issues.apache.org/jira/browse/SOLR-16681
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Mikhail Khludnev
> Priority: Minor
> Fix For: 9.2
>
> Attachments: image-2023-02-26-09-48-31-974.png,
> image-2023-02-26-09-48-59-323.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> User reported a use case which were working before 9 but not anymore.
> The point is to logically replace a field (hereby it's {{id}} {-}but it might
> behave same for any other{-})
> {{fl=old_id:id,id:new_id}}
> I'd say it's a kind of {{{}$mv new_id id{}}}. I've made a simple
> [reproducer|https://github.com/apache/solr/pull/1384].
> it fails with
> {code:java}
> - org.apache.solr.cloud.TestCloudPseudoReturnFields.test_mv_fl (:solr:core)
> [7597|https://github.com/apache/solr/actions/runs/4276380498/jobs/7444431149#step:4:7598]
> Test output:
> /tmp/src/solr/solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.cloud.TestCloudPseudoReturnFields.txt
>
> [7598|https://github.com/apache/solr/actions/runs/4276380498/jobs/7444431149#step:4:7599]
> Reproduce with: gradlew :solr:core:test --tests
> "org.apache.solr.cloud.TestCloudPseudoReturnFields.test_mv_fl"
> -Ptests.jvms=96 "-Ptests.jvmargs=-XX:TieredStopAtLevel=1 -XX:+UseParallelGC
> -XX:ActiveProcessorCount=1 -XX:ReservedCodeCacheSize=120m"
> -Ptests.seed=4CCEBE424880B511 -Ptests.file.encoding=US-ASCII
> {code}
> . [Then I applied
> it|https://github.com/mkhludnev/solr/tree/SOLR-16681-proves-work-before] to
> revision preceding
> [SOLR-9376|https://github.com/mkhludnev/solr/commit/6ff81312607dd5d33f87dc52aed9d52938dc6883#diff-e72c1360a9b0097bcc01e269a94045ce5af1fdc93ae3021ca7e8d1b26d46bdcb]
> and test passed. For me it seems like:
> - Solr behaved like described before, but it does not after SOLR-9376.
> - Should we reproduce this behavior or we can suggest a workaround?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
