I'm assuming the type ids here are a different set than the type ids used with regular PDX serialization so they won't conflict if the pdx registry assigns 1 to some class and a user puts @typeId: 1 in their json?
I'm concerned that this won't really address the type explosion issue. Users that are able to go to the effort of adding these typeIds to all of their json are probably users that can produce consistently formatted json in the first place. Users that have inconsistently formatted json are probably not going to want or be able to add these type ids. It might be better for us to pursue a way to store arbitrary documents that are self describing. Our current approach for json documents is assuming that the documents are all consistently formatted. We are infer a schema for their documents store the field names in the type registry and the field values in the serialized data. If we give people the option to store and query self describing values, then users with inconsistent json could just use that option and pay the extra storage cost. -Dan On Tue, Dec 20, 2016 at 4:53 PM, Udo Kohlmeyer <ukohlme...@gmail.com> wrote: > Hey there, > > I've just completed a new proposal on the wiki for a new mechanism that > could be used to define a type definition for an object. > https://cwiki.apache.org/confluence/display/GEODE/Custom+ > External+Type+Definition+Proposal+for+JSON > > Primarily the new type definition proposal will hopefully help with the > "structuring" of JSON document definitions in a manner that will allow > users to submit JSON documents for data types without the need to provide > every field of the whole domain object type. > > Please review and comment as required. > > --Udo > >
