+1 for self describing documents -- Mike Stolz Principal Engineer, GemFire Product Manager Mobile: 631-835-4771
On Wed, Dec 21, 2016 at 9:20 PM, Dan Smith <dsm...@pivotal.io> wrote: > 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 > > > > >
