You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We presently use ION schemas to validate incoming ion documents.
We have a data transform use case where we are extracting data from multiple sources (CSV, DynamoDB, wikis, etcs) and would like to convert all of that to ion documents. We would also like to keep the transformation logic across multiple tools updated for changes made to the ion schema. Presently, we need to ensure that the transformation logic is updated whenever the underlying schemas are updated.
With automated class definition generation in place, it would be possible for us to simplify the transformations. We would also be able to implement build verification tests that fail when there is incompatibility between the schema and the corresponding Java tools.
The text was updated successfully, but these errors were encountered:
abhijit10m
changed the title
Add support for generation of POJOs from Ion Schema.
Add support for generation of java .class files from Ion Schema.
May 19, 2020
Thank you, Abhijit--this certainly sounds useful, and is effectively the inverse of #89.
Capturing a few additional thoughts:
open content: care should be taken to avoid generating code that drops open content (e.g., copy known fields from an Ion struct to fields of a POJO, then discard the struct--open content is lost; one alternative is to preserve the original Ion struct and have the getters/setters operate on the struct)
annotations: similarly, annotations should somehow be preserved
POJO vs. POJI: we should consider tradeoffs between generating POJOs or POJIs (plain-old Java interfaces) with a generic java.lang.reflect.Proxy impl
would generated setters be expected to perform additional validation based on the schema's constraints for a field?
some valid ISL presents interesting questions, e.g.: if a struct field is constrained by not: string, what should be generated?
proper handling of imports and the type constraint should be considered
I had an offline conversation with an Ion user who wants to generate POJOs that have annotations for controlling how the POJO gets serialized/deserialized by Jackson.
We should consider providing an API in this tool that would allow users to inject their own framework-specific code into the POJO generation process to support this and other use cases that require specific annotations on POJOs.
The text was updated successfully, but these errors were encountered: