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 (www.blackberry.com) > ------------------------------ > *From: *"Thacker, Dharam" <[email protected]> > *Sent: *Dec 27, 2017 14:03 > *To: *John Blum <[email protected]>; [email protected] > *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 it. 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 PDX. 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, ;-) [1] https://github.com/spring-projects/spring-data-geode/blob/2.0.2.RELEASE/src/main/java/org/springframework/data/gemfire/serialization/json/JSONRegionAdvice.java#L267-L288 > > *Description: * > > Possibly using AOP but at high level it encapsulates “JSONFormatter” api > but stricter part “It needs entity/schema/pojo” > > > > > > I also know about recent introduction of “*@EnableEntityDefinedRegions*” > to avoid cumbersome definition of all region beans in config. > > I think that’s an annotation which can help if extended to overcome above > explained limitations at some extent. > > > > ð Now a days lot of databases (Oracle 12c ,MariaDB 10.2 etc.) provides > native support for json storage and powerful json functions to query > underlying data > > ð Even ORM frameworks works well and compatible enough as shown in below > example, > > > > @Entity > > class Customer { > > @Id > private String cid; > > * @Lob* > > *private String customerDetails;* > > } > > > > ð As shown above, above class will be loaded with full json contents > from database but now there is *complete disconnect with NO-SQL store to > RDBMS system*. > ð There is *no good way* you can play around “customerDetails” json with > nested structure in Geode if you store your POJO as it is in “/Customer” > region > > ð The way we use as of now [ > *customerTemplate.put(customer.getCid(),JsonFormatter.fromJson(customer.getCustomerDetails())* > ] > > 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* > > > > ð As per my understanding, I see that possibly extension of > “*@EnableEntityDefinedRegions” > *could help here > > ð It would require few more hooks to properly auto convert @Lob in JPA > vs @Json in GEODE to auto convert it to PDXInstance when storing to region > 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. [2] https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/mapping/package-frame.html ð It would also require few more annotations to define co-location of > similar regions so that one can use all possible region types > > > Hence, this [3], and specifically this [4], or all of these [5]. [3] https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/mapping/annotation/PartitionRegion.html [4] https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/mapping/annotation/PartitionRegion.html#collocatedWith-- [5] https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/mapping/annotation/package-summary.html > Hope it makes sense! > > > > Let us know your thoughts as well. > 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. Cheers! > > Thanks & Regards, > > Dharam > > > > This message is confidential and subject to terms at: http:// > www.jpmorgan.com/emaildisclaimer including on confidentiality, legal > privilege, viruses and monitoring of electronic messages. If you are not > the intended recipient, please delete this message and notify the sender > immediately. Any unauthorized use is strictly prohibited. > -- -John john.blum10101 (skype)
