Subject: Proposal on new features [Json Extension]

Hi Dharam-

Sorry; I have been out on extended holiday and I am still catching up.
Comments below...
On Tue, Jan 9, 2018 at 8:15 PM, Thacker, Dharam <[EMAIL PROTECTED]
> wrote:

> Hello Team,
> Any thoughts on this?
> Regards,
> Dharam
> Sent with BlackBerry Work (
> ------------------------------
> *From: *"Thacker, Dharam" <[EMAIL PROTECTED]>
> *Sent: *Dec 27, 2017 14:03
> *Subject: *Proposal on new features [Json Extension]
> Hi John & Team,
> I would like to discuss about proposal for new feature with regards to
> JSON documents in GEODE mainly intended for spring-data-geode.
> *What is available and trade offs?*
> I am aware of following ways but let me explain!
> 1.      Region <Serializable,PDXInstance> [JSONFormatter.fromJson(json)]
> *Description:*
> This is powerful api to store literally *any JSON document into region
> without worrying about underlying schema*. But it comes up with several
> tradeoffs as explained below,

Any JSON document might be questionable, actually.  JSONFormatter is a
crude implementation that effectively just maps JSON to/from PDX.  I would
question it's utility to map a variety of highly complex JSON documents.
Apache Geode is not a "document" store unlike MongoDB, Couchbase, etc.

> a.      As there is no entity defined pojo, one will not be able to take
> advantage of *recent pdx-jdbc*  mappings possibly going to be part of
> Apache-Geode-1.4.0
I do not endorse the pdx-jdbc mapping functionality in SDG.

> b.      As it is PdxInstance, implementing “Delta” interface is tricky
> and complex to get information on what has changed inside document.
Using *Deltas* with PDX defeats the purpose of PDX.  If you implement the
*Delta* interface and serialize with PDX, you are going to
serialize/de-serialize your instance every single time since Geode needs to
"invoke a method" to apply the delta.

> c.       Colocation strategy is not possible as explained in “point – a”
> due to missing pojo/well defined schema. One has to create REPLICATED
> REGION if he is intended to use “EQUI JOIN” with other regions
Not sure I follow you here.

> d.      *<There might be few more I am not aware of but you can help> *J
> 2.      <gfe-data:json-region-autoproxy/> [Useful when you know the
> schema and play around with your entity objects]

Not exactly.  Why do you need to know the schema?  Perhaps I am not
understanding you here, but 1 of 3 things happen when auto-proxying a
Region with JSON support...

1. First, if the incoming object is already a PdxInstance, then just store
2. If the incoming object is a String (i.e. JSON), then use the
JSONFormatter to map to PDX.
3. However, if the incoming object is a domain type, use *Jackson* to
convert it to JSON and then use the JSONFormatter to map it to PDX.

This is apparent from the AOP Advice ([1]).

Clearly, you can just store raw JSON too, as a value in the Region, but
that is not as useful since you cannot query it using OQL as you can with

NOTE: actually, maybe you are implying #3 here.

The real power of this is in #3 actually since it uses Jackson first to
convert the object to JSON, respecting all Jackson mapping meta-data,
before mapping to PDX using the JSONFormatter.  But then, sure you sort of
have a schema-structure defined by the Object.  However, that depends on
the mapping meta-data and whether are storing arbitrary objects/documents
in the same Region.  Nothing prevents you from storing Customers and Orders
in the same Region just because it is mapped to JSON with Jackson and then
PDX with JSONFormatter, for instance  Of course, why would anyone do that;
that's crazy, ;-)
> *Description: *
> Possibly using AOP but at high level it encapsulates “JSONFormatter” api
ð  There is *no good way* you can play around “customerDetails” json with
I would argue that having raw JSON stored in a field or property domain
object (assuming that is the purpose of @Lob private String
customerDetails) is not good design; even by ORM tool standards. #yuck
This to me seems to be the data store storage capabilities bleeding into
the domain model.
*Possible Extension*
Honestly, this second point suggests it has more to do with the SD
"mapping" infrastructure (based in [2]) than it does
@EnableEntityDefinedRegions, suggested in point 1.


ð  It would also require few more annotations to define co-location of

Hence, this [3], and specifically this [4], or all of these [5].


Hope it makes sense!

Honestly, and presently, I am not crazy about this idea and I will need to
think on this more, after re-reading this several times.

Thanks for sharing your thoughts/ideas.


john.blum10101 (skype)