Thanks Erik. I created SOLR-13699. I agree wrt adding a Unit Test, that was my thinking as well. I am currently working on a test, and then I will submit my patch.
Thanks, Chris On Thu, Aug 15, 2019 at 1:06 PM Erick Erickson <erickerick...@gmail.com> wrote: > Chris: > > I certainly don’t see anything in JIRA about this, so please do raise a > JIRA, > especially as you already have a patch! > > It’d be great if you added a test case demonstrating this that fails > without > your patch and succeeds after. I’d just add a method to one of the > existing tests, maybe in > solr/core/src/test/org/apache/solr/schema/CopyFieldTest.java? > > No need to make this a SolrCloud test. > > Best, > Erick > > > On Aug 15, 2019, at 11:31 AM, Chris Troullis <cptroul...@gmail.com> > wrote: > > > > Hi all, > > > > We recently upgraded from Solr 7.3 to 8.1, and noticed that the maxChars > > property on a copy field is no longer functioning as designed. Per the > most > > recent documentation it looks like there have been no intentional changes > > as to the functionality of this property, so I assume this is a bug. > > > > In debugging the issue, it looks like the bug was caused by SOLR-12992. > In > > DocumentBuilder where the maxChar limit is applied, it first checks if > the > > value is instanceof String. As of SOLR-12992, string values are now > coming > > in as ByteArrayUtf8CharSequence (unless they are above a certain size as > > defined by JavaBinCodec.MAX_UTF8_SZ), so they are failing the instanceof > > String check, and the maxChar truncation is not being applied. > > > > I went to log a bug but figured I would double check on here first just > to > > confirm that people think that this is actually a bug and I'm not going > > crazy. Let me know what you think, and I will log the bug. > > > > I have implemented a fix which I am currently testing and will be happy > to > > submit a patch, assuming it's agreed that this is not intended behavior. > > > > Thanks, > > Chris > >
