Hi Brian,

I got the schema from C# source code generator working, at least well enough 
for us. Not sure it is ready for general use but if you’re interested I can 
send the code. What is the usual practice for things under development - should 
I create a PR even if the code is some way off from being mergeable or just a 
branch of my repo?

Our use case is that the developers write C# DTO classes and don’t need to 
worry much about the schema. We build a protocol from the classes and then 
schemas for each top level object from the protocol. 

Also, I think we (Pitney Bowes) need to get something going about a JSON 
encoder. Shifting to Avro is a bit of a stretch for some of our developers 
since they can’t easily see the message contents without additional decoding 
tools. Are you ok with basing it on JSON.net? It should be pretty fast to get 
something working.

> On Jul 11, 2019, at 5:05 PM, Brian Lachniet <[email protected]> wrote:
> 
> Hi Patrick!
> 
> I'm sorry I haven't gotten back to the Reflect review yet. I'm hoping to
> get back on that this weekend.
> 
> That sounds like a good list of additions. I'm particularly interested in
> having support for JSON encoding/decoding in C#. I bet we could get a long
> ways simply porting the JsonEncoder
> <https://github.com/apache/avro/blob/master/lang/java/avro/src/main/java/org/apache/avro/io/JsonEncoder.java>
> from the Java bindings.
> 
> I agree that we need to bump the Newtonsoft.Json verison. That just came up
> in another issue recently. What version of Newtonsoft.Json do you think we
> should upgrade to? I'm a little wary of bumping all the way to the latest,
> as that would force everyone using Avro to also go to the latest version.
> Maybe that's not a bad thing, I'm not sure.
> 
> I'm not familiar with Roslyn-based code generation. I'll do some Googling
> on that (if you've got some good articles or starting points to share, I'd
> appreciate that). Codegen currently uses the System.CodeDom API. Would
> Roslyn-based code generation be a replacement for that, or am I
> misunderstanding something?
> 
> Thank you for your patience so far, Patrick. I'm looking forward to these
> new features too!
> 
> On Thu, Jul 11, 2019 at 6:14 PM Patrick Farry <[email protected]>
> wrote:
> 
>> Hi Brian,
>> 
>> Not meaning to hassle you (well maybe a little). I’ve got a few other
>> enhancements we'd like to do as well as the Reflect code, and was hoping
>> not to have to maintain a bunch of branches.
>> 
>> Here are the planned changes:
>> - update newtonsoft.json and add the json path whenever the schema parser
>> reports an error - we have a number of large schemas and debugging them is
>> proving difficult
>> - Roslyn based schema generator from C# class
>> - Reflect option added to codegen (possibly updating codegen to use Roslyn)
>> - Serialize to json
>> 
>> Thanks.
>> 
>>> On May 2, 2019, at 6:22 PM, Brian Lachniet <[email protected]> wrote:
>>> 
>>> Hey Patrick,
>>> 
>>> This sounds very useful! I'd love to see this introduced to the C#
>> library.
>>> 
>>> On Thu, May 2, 2019 at 5:47 PM Ivan Greene <[email protected]>
>>> wrote:
>>> 
>>>> Patrick,
>>>> 
>>>> This sounds as though it would be the C# equivalent of Java's
>> ReflectData,
>>>> which has been part of the Avro API for several years now, so it’s
>> likely
>>>> there would be interest. Your best bet is to open a Jira describing the
>>>> planned feature and open a pull request on Github to start the
>> discussion.
>>>> The contributing page on the wiki is a bit out of date and still
>> recommends
>>>> submitting patches on Jira but I believe that Github is now the official
>>>> repository.
>>>> 
>>>>> On May 1, 2019, at 4:31 PM, Patrick Farry <[email protected]>
>>>> wrote:
>>>>> 
>>>>> Hi All,
>>>>> 
>>>>> I have written code that implements Avro serialization for POCO classes
>>>> - i.e. classes that are not generated by Avro codegen and do not
>> implement
>>>> ISpecificRecord. The idea was to make it work as much like JSON.net as
>>>> possible.
>>>>> 
>>>>> The serializer inherits from SpecificDefaultWriter and the deserializer
>>>> from SpecificDefaultReader.
>>>>> 
>>>>> Avro fields are mapped to C# properties either by matching the field
>>>> name and property name or by using an attribute to specify the field
>>>> sequence number.
>>>>> 
>>>>> Is this something that would be of interest to the Avro project? My
>>>> company has approved committing the code and I’d be available and happy
>> to
>>>> maintain this code and work on other parts of the C# implementation.
>>>>> 
>>>>> Regards.
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> --
>>> 
>>> [image: 51b630b05e01a6d5134ccfd520f547c4.png]
>>> 
>>> Brian Lachniet
>>> 
>>> Software Engineer
>>> 
>>> E: [email protected] | blachniet.com <http://www.blachniet.com>
>>> 
>>> <https://twitter.com/blachniet> <http://www.linkedin.com/in/blachniet>
>> 
>> 
> 
> -- 
> 
> [image: 51b630b05e01a6d5134ccfd520f547c4.png]
> 
> Brian Lachniet
> 
> Software Engineer
> 
> E: [email protected] | blachniet.com <http://www.blachniet.com>
> 
> <https://twitter.com/blachniet> <http://www.linkedin.com/in/blachniet>

Reply via email to