[ https://issues.apache.org/jira/browse/SOLR-8767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16461800#comment-16461800 ]
Simon Rosenthal commented on SOLR-8767: --------------------------------------- +1 on changing the behavior. Was just bitten by this real-time get behavior in a situation where I was using a copyfield to effectively rename a -->b (a was then defined as non-indexed, non-stored). Not the intended use of copyfield, I know, and I could probably use a FieldNameMutatingUpdateProcessor instead (though this results in including field name manipulations in solrconfig.xml, where it really doesn't belong, rather than in the schema). > RealTimeGetComponent and stored/copyField exclusion > --------------------------------------------------- > > Key: SOLR-8767 > URL: https://issues.apache.org/jira/browse/SOLR-8767 > Project: Solr > Issue Type: Bug > Components: SolrCloud > Reporter: Erik Hatcher > Priority: Critical > > Consider this scenario: schema has fields `a` and `b` defined, both stored. > A copyField is defined from `a` => `b`. A document is indexed with `id=1; > b="foo"`. A real-time /get will not return field `b` because > RealTimeGetComponent.toSolrDoc currently excludes copyField destinations > (despite, in this situation, the source of that copyField not being sent in). > Granted this is a bit of a diabolical case (discovered while tinkering with > cloud MLT tests), but isn't that far fetched to happen in the wild. > Maybe real-time /get should return all fields set as stored, regardless of > copyField status? -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org