I don't see how the lack of an entity-defined pojo limits co-location. Co-location must always be achieved via data that is resident in the key of the entry. PartitionResolver cannot use anything in the payload itself, because the PartitionResolver is called in the case of get(key) as well as put(key, value), and in the case of get(key), there is no payload to extract partition information from. All you have is the key. Therefore the type of the payload cannot affect co-location.
-- Mike Stolz Principal Engineer, GemFire Product Lead Mobile: +1-631-835-4771 Download the new GemFire book here. <https://content.pivotal.io/ebooks/scaling-data-services-with-pivotal-gemfire> On Tue, Jan 9, 2018 at 11: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, > > > > 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 > > b. As it is PdxInstance, implementing “Delta” interface is tricky > and complex to get information on what has changed inside document. > > 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 > > 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] > > > > *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())* > ] > > > > *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 > > ð It would also require few more annotations to define co-location of > similar regions so that one can use all possible region types > > > > Hope it makes sense! > > > > Let us know your thoughts as well. > > > > 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. >
