Bug: Type definition page incorrectly formatted for types with complex members

[mphuff]

There is a bug when generating the type definition pages that appears to be linked to a type definition having a complex member variable. When outputting these types (DateRange in the attached example), the definition is output numerous times rather than a single time with a list of protocols that define it.

Compare the output of Date and DateRange in the sample.html file from this gist: https://gist.github.com/mphuff/5461540

This Sample.html file was generated from this command: avrodoc ProtoclA.avsc ProtocolB.avsc ProtocolC.avsc --output=Sample.html

[ept]

@mphuff Thanks, agree that this is a bug. However I'm afraid your fix is not correct — it makes the _(new_type).isEqual(typeEssence(...)) comparison always true (so any actual differences between types with the same name will no longer be found).

Working on a fix now.

[ept]

The problem is that at the beginning of defineNamedType, the types of fields are not yet resolved to their definitions. If unqualified types are used, typeEssence for the new schema has unqualified names for the fields, whereas typeEssence for the existing schema has fully qualified names for the fields.

[mphuff]

@ept -- I gotcha...let me know when you've got a fix in place and I'll give it a look over and evaluate it against our large doc project.

Thanks.

[mphuff]

@ept -- Any update on when you may get a chance to look into this more? I can try to spend some cycles on it but it sounded like you had an idea of a way to fix this in mind. This is causing us more and more grief day-by-day and I'd like to see if we could get this issue resolved and released.

Thanks!