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
{{ message }}
This repository was archived by the owner on Mar 8, 2020. It is now read-only.
Sometimes (or almost always) native objects that have a semantic mapping have more properties than the ones we have in our schema. What to do with them? This is more evident with the latest SDK update that produces and error when you silently drop any field on the semantic mapping.
Possible solutions:
Drop them explicitly.
Pros: trivial to implement. User could still have access in the non semantic UAST.
Cons: It's ugly to lose information in the semantic UAST.
Add an extra or similar field on GenNode where these properties can be loaded.
Pros: easy to implement.
Cons: turns the semantic objects into "schema-less" at least regarding the contents of the extra field.
Add an SDK feature to get a list of strings and create a group where these properties are together with the semantic node. Then call that on the Normalize transform. It's similar to 2), but with the properties one level above instead of into the semantic object. This is similar to what the C# and Python driver do (in different ways) to keep comments.
Pros: easy to implement (on the drivers, unsure about the SDK feature itself).
Cons: more noisy semantic UAST. Adds groups without real semantic meaning. Have to implement feature in the SDK. More boilerplate for the driver programmer. Won't always work for all drivers (the C# driver for example sometimes maps the comments inside properties instead of a parent group).
Continue writing custom transforms for each driver like the C# and Python driver do.
Pros: will work for each driver.
Cont: Very cumbersome to write and maintain, ugly, fails the DRY principle since most will be similar but not equal.
Other solutions...?
This is semi-urgent since the latest SDK made mandatory to map these fields.
The problem:
Sometimes (or almost always) native objects that have a semantic mapping have more properties than the ones we have in our schema. What to do with them? This is more evident with the latest SDK update that produces and error when you silently drop any field on the semantic mapping.
Possible solutions:
Drop them explicitly.
Pros: trivial to implement. User could still have access in the non semantic UAST.
Cons: It's ugly to lose information in the semantic UAST.
Add an
extraor similar field onGenNodewhere these properties can be loaded.Pros: easy to implement.
Cons: turns the semantic objects into "schema-less" at least regarding the contents of the
extrafield.Add an SDK feature to get a list of strings and create a group where these properties are together with the semantic node. Then call that on the
Normalizetransform. It's similar to 2), but with the properties one level above instead of into the semantic object. This is similar to what the C# and Python driver do (in different ways) to keep comments.Pros: easy to implement (on the drivers, unsure about the SDK feature itself).
Cons: more noisy semantic UAST. Adds groups without real semantic meaning. Have to implement feature in the SDK. More boilerplate for the driver programmer. Won't always work for all drivers (the C# driver for example sometimes maps the comments inside properties instead of a parent group).
Continue writing custom transforms for each driver like the C# and Python driver do.
Pros: will work for each driver.
Cont: Very cumbersome to write and maintain, ugly, fails the DRY principle since most will be similar but not equal.
Other solutions...?
This is semi-urgent since the latest SDK made mandatory to map these fields.