Re: New proposal for type definitons

Why don't we just support the Jackson DeserializationOptions? Some people are going to want BigDecimals instead of floating-point numbers because they're dealing with monitary values. Le 1/10/2017 à 6:40 AM, Jacob Barrett a écrit : On Mon, Jan 9, 2017 at 4:14 PM Darrel Schneider

Re: New proposal for type definitons

On Mon, Jan 9, 2017 at 4:14 PM Darrel Schneider wrote: > Pdx stores and index at the end of the blob so that it can lookup any of > the > fields without reading the preceding fields. > Thanks for that correction. If you stored every JSON number as a BigDecimal this

Re: New proposal for type definitons

oposal was more of > an > > >>> external tool or wrapper focused on sanitizing json documents without > > >> being > > >>> concerned with type ids or a central registry service. I could > picture > > >> just > > >>> having a s

Re: New proposal for type definitons

; json > >>> schema<http://json-schema.org/> and returns a cleaned up json > document. > >>> That seems like it would be a lot easier to implement and wouldn't > >> require > >>> the user to add typeIds to their json documents. > >>> > >

Re: New proposal for type definitons

torage cost. > > > Dan, are you saying expose some interface to serialize/de and "query > the > > > some field in data - getFieldValue(fieldname)" dtata? Some sort of > > > ExternalSerializer with getFieldValue() capability. > > > > > >

Re: New proposal for type definitons

; just use that option and pay the extra storage cost. > > > Dan, are you saying expose some interface to serialize/de and "query > the > > > some field in data - getFieldValue(fieldname)" dtata? Some sort of > > > ExternalSerializer with getFieldValue() capability.

Re: New proposal for type definitons

> Dan, are you saying expose some interface to serialize/de and "query the > > some field in data - getFieldValue(fieldname)" dtata? Some sort of > > ExternalSerializer with getFieldValue() capability. > > > > > > From: Dan Smith <dsm...@pivotal.io>

Re: New proposal for type definitons

gt; some field in data - getFieldValue(fieldname)" dtata? Some sort of > ExternalSerializer with getFieldValue() capability. > > > From: Dan Smith <dsm...@pivotal.io> > To: dev@geode.apache.org > Sent: Wednesday, December 21, 2016 6:20 PM > Subject: R

Re: New proposal for type definitons

ame)" dtata?  Some sort of ExternalSerializer with getFieldValue() capability. From: Dan Smith <dsm...@pivotal.io> To: dev@geode.apache.org Sent: Wednesday, December 21, 2016 6:20 PM Subject: Re: New proposal for type definitons I'm assuming the type ids here are a different

Re: New proposal for type definitons

A little late to the game here but I want to go back to Dan's idea of storing the JSON or other self describing objects as a first class object in Geode. As it stands right now an entry can be a POJO, Java serialized object, or PDX, so why not other types? Seems perfectly reasonable to allow first

Re: New proposal for type definitons

You are correct here. Ordering the fields would be a simple solution IF the only problem was that fields were incorrectly ordered. In most cases not all fields are provided thus causing an explosion of type definitions that would be generated. On 12/22/16 16:11, Darrel Schneider wrote: When

Re: New proposal for type definitons

This is pretty interesting actually. It brings back the good parts of formal schema design. -- Mike Stolz Principal Engineer, GemFire Product Manager Mobile: 631-835-4771 On Fri, Dec 23, 2016 at 11:09 AM, Bruce Schuchardt wrote: > I wonder if it would be helpful to use

Re: New proposal for type definitons

I wonder if it would be helpful to use JSON Schema as a starting point for this effort? Le 12/22/2016 à 6:45 PM, Udo Kohlmeyer a écrit : Ok, I will try and explain all of this better. --Udo On 12/22/16 16:42, Darrel Schneider wrote: The @refTypeId is hard to

Re: New proposal for type definitons

Ok, I will try and explain all of this better. --Udo On 12/22/16 16:42, Darrel Schneider wrote: The @refTypeId is hard to understand. It is unclear to me how it interacts with other things like "dataType" and "subType". I think you can either specify a dataType/subType OR a @refTypeId. Is

Re: New proposal for type definitons

The thought was to process the type definition and optimize before generating the type def. Making it more generic or "wider" is a good idea. Maybe I try and keep to the already defined PDX types and see how they could map. --Udo On 12/22/16 16:11, Darrel Schneider wrote: When generating

Re: New proposal for type definitons

I think the spec needs to be further extended. This was just draft 1 with the hope to spark some thought. I'll continue refining over time. The thought was to make it a generic "catalogue" which could potentially drive all type definitions, regardless of serialization mechanism. --Udo On

Re: New proposal for type definitons

Correct, The user will not be able to override an existing typeId + type definition. It will fail with the error message that an previous definition already exists. I imagine the process would be to remove a typeId (later feature) which could check if any data exists for that typeId. If no

Re: New proposal for type definitons

The @refTypeId is hard to understand. It is unclear to me how it interacts with other things like "dataType" and "subType". I think you can either specify a dataType/subType OR a @refTypeId. Is this correct? The current spec makes it look like you can specify both but your example just show one or

Re: New proposal for type definitons

+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 wrote: > I'm assuming the type ids here are a different set than the type ids used > with regular PDX serialization so

Re: New proposal for type definitons

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