This sounds like a bug. There is logic in SpecificCompiler#generateMethodName to try to avoid name conflicts, but it's clearly faulty in this case. One could add a flag that inhibited underscore removal, which would help here. What might be better would be have a table of method names that have been generated, have compile(Schema) method clear the table, then have generateMethodName store each generated name in the table, and, when a name conflicts, suffix it with a $ or number until it doesn't conflict.
Please file an issue in Jira. https://issues.apache.org/jira/projects/AVRO Thanks, Doug On Mon, Aug 28, 2017 at 9:30 AM, McCullough, Alex < alex.mccullo...@capitalone.com> wrote: > Hey All, > > > > I have an avro scheme that defines two fields with very close names such > as: > > · field_random_name > > · fieldrandom_name > > > > Now from a schema perspective these are unique names, but when the Java > classes are generated I have issues because the underscores are removed and > the fields end up the same and ultimately cause the create of duplicate > methods with the same signature. > > > > Is there a solution to this so the java class methods retain the > underscores? I realize your first response might be, naming fields like > that is crazy, just change the field names…. Unfortunately, these are > client defined schemas and messages and so changing them is not so straight > forward, I wanted to explore other options before saying that’s the only > way to reasonably manage this. > > > > Let me know if you need any other info. > > > > Thanks, > > Alex > > > > ------------------------------ > > The information contained in this e-mail is confidential and/or > proprietary to Capital One and/or its affiliates and may only be used > solely in performance of work or services for Capital One. The information > transmitted herewith is intended only for use by the individual or entity > to which it is addressed. If the reader of this message is not the intended > recipient, you are hereby notified that any review, retransmission, > dissemination, distribution, copying or other use of, or taking of any > action in reliance upon this information is strictly prohibited. If you > have received this communication in error, please contact the sender and > delete the material from your computer. >
