Okay, the idea of using the converters when using the data rather than at ingest is quite intriguing and could be a very valuable aspect of the product, especially if it's easy to use. (We do have CacheListeners and the like now, but you have to understand the abstraction and then write some Java code, etc.) Converters could even potentially be plugged into datastores to persist data in a particular format.
If Spring does what we want with reasonably small effort, I'd say let's use it, and keep it one interface that's modular enough that we can replace it with our own service if we really need to get rid of Spring for some reason. -Galen On Thu, Jan 26, 2017 at 12:23 PM, Jacob Barrett <jbarr...@pivotal.io> wrote: > On Thu, Jan 26, 2017 at 11:36 AM Galen M O'Sullivan <gosulli...@pivotal.io > > > wrote: > > > I think the reason we use JSON is because it's easy. I'm not convinced > that > > 90% of JSON data is from JavaScript, unless you have data to back that up > > -- a lot of scripting languages use it because it's convenient. > > > > Excuse my hyperbole. Wether the user is JavaScript, Python or whatever the > issue that like, JavaScript, JSON does not have rich datatypes and trying > to infer those types from the data is dangerous. JSON, YAML, etc. are only > useful both sides of the persistence agree on the same schema for the types > ultimately attributed to the value when parsed. Since Geode does not > require you to pre-define a schema for your data we attempt to infer type > information and create a structured datatype based on the inference. Then > when someone wants to get that data back out we convert our inferred data > to JSON and pass it back. That translation between untyped to typed back to > untyped is where we get caught up. Its like passing a phrase to Google > translate, passing the translation back through the way and expecting to > get the same phrase, try it, it gets strange fast. > > For unstructured data, like JSON, we should persist the original. Doing > anything else complicates the issue of the round trip result described > above. If the values need to be coerced into something else, say for > indexing, then it should only be done at the time of indexing or use. This > is where "converters" are a natural fit. Consider indexing command, "create > index foo on value.foo as type time with converter MyCustomDateConverter". > The indexer would invoked java.util.Date > MyCustomDateConverter.convert(Object value) when indexing that column. > > -Jake >
