Hi John, Thanks for your reply. Indeed, we are trying to maintain some level of backwards compatibility in the schema, and Fixed is what was used from the beginning. That is certainly an option worth considering internally though, in case our team thinks this is important enough to break that backwards compatibility. My guess is that we'd probably post-process the output of the JSON with an external utility and convert fields as-needed before we'd alter the schema. But our ideal case would be to add in some code to make our tweaks only to the JSON encoding at runtime.
Thanks, Tim On Tue, Mar 7, 2017 at 10:44 AM, John McClean <[email protected]> wrote: > If you want a string representation, can you use 'string' as the type > rather than 'fixed'? Or is the issue that you have data conversion / > backwards compatibility constraints? > > On Tue, Mar 7, 2017 at 6:51 AM, Tim Upthegrove <[email protected]> > wrote: > >> Hi folks, >> >> I am trying to add a convenience method for my team that can serialize an >> Avro record in the C++ bindings to JSON with a few minor customizations. >> For example, our schema encodes UUIDs as Fixed types, and they are the only >> fields which are a Fixed type with the particular length of a UUID. We'd >> like to encode those UUIDs in the JSON output according to the RFC 4122 >> specified UUID format instead of a unicode escape sequence for ease of >> debugging. >> >> Since we only have a few minor changes, I initially thought it would make >> sense to use inheritence for this, but looking at the JsonGenerator and >> JsonEncoder classes that currently exist, this seems like it could be >> challenging. Continuing with the UUID example, the specific method I'd >> want to override (escapeCtl at https://github.com/apache/a >> vro/blob/master/lang/c++/impl/json/JsonIO.hh#L214) and the StreamWriter >> for building the JSON string are both private to the JsonGenerator class. >> >> Is there an easy way to achieve what I describe in the example above in >> the C++ bindings that I am missing or overlooking? If not, is there any >> reason why those methods should not be changed from private visibility to >> protected so I could accomplish this through inheritence? >> >> Thanks, >> -- >> >> Tim Upthegrove >> > > -- Tim Upthegrove
