JsonExtensionData support

[mcgear]

Is your feature request related to a problem? Please describe.
In order to achieve some of our various logic, we have been leveraging JsonExtensionData concepts from JSON.NET. In the previous supporting library we were using, we were able to easily pass across these metadata. Now converting everything in our Graph over to Gremlinq, we have hit an error where JsonExtensionData blows up the Graph calls.

The way that JsonExtensionData works, is it typically flattens what is in the Dictionary property down to properties on the actual base object. leveraging this, we can do some dynamic data storing.

After cracking open the code and adding a few new tests that broke at first, the largest issue seems to be the relation properties have to the GraphModel.

Describe the solution you'd like
Ideally, when processing a Property with JsonExtensionData attribute, the desired behavior would be that every item in the dictionary show up on the base level object written to the graph.

Describe alternatives you've considered
I have jumped into my own fork and solved issues around AddV, Property, and Where as a proof of concept, and it seems to be working. Seeing as i don't have the experience in your code base yet, i thought i would pause and surface this here. I figure there are still changes required to support things like FirstAsync and ToArrayAsync, more importantly you may have a completely different thought and approach than what i was able to figure out to get it working.

[danielcweber]

I don't have a definitive opinion about whether to embrace such a feature or not. My initial feelings towards this are:

• There have been multiple requests to include more awareness for various Json.NET attributes in the core library, but I am usually against those proposals because not everybody might have access to the entities source code. Besides that, any way of using attributes will eventually have a fluent-configuration counterpart and there's just not the time and money to support these long term.
• Dependency on Json.NET will have to go eventually. So rather than adding more code that depends on Json.NET I'd see a pluggable architecture to serialize entities into (key, value) pairs that can rely on Json.NET but doesn't need to.
• I had a look into your work and it seems straightforward. I'm not sure how entity deserialization would work as you would desire, but maybe you'll figure that out.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[LoungeFlyZ]

this would be very helpful @mcgear. Did you get any further with this and complete the implementation? if not, what did you do instead?

[sebastianamaro]

Hi @danielcweber! I understand that there was no fix on the code regarding this right?

Is there any suggested workaround for supporting dynamic properties? I mean not strongly typed properties, that might be added by the user.