RE: DynaModel with spring-data-geode

["Thacker, Dharam" <dh...@jpmorgan.com>]

Any suggestions/thoughts on this?

Thanks,
Dharam

From: Thacker, Dharam
Sent: Thursday, November 29, 2018 7:37 PM
To: user@geode.apache.org
Subject: DynaModel with spring-data-geode

Hi John & Team,

I need some help with below 2 annotations which I think can be extended to give more power. Let me try to explain it.

@EnableEntityDefinedRegions
@EnableClusterConfiguration

As of now, it has enabled client apps to push regions to server with unified cluster configuration (And not required to use GFSH/Server java api)

Why does it make sense?
Lots of times, change triggered in 1 system requires multiple downstream systems to change. It could be business driven/optimistic/to be used/dormant/deprecation related changes.
To achieve this, I have chosen JSON documents (And at some places PROTO, but I will take JSON's example)

Assumption:

1.       It's GEODE as FRONT FACING and some DOCUMENT STORE(Mongo/Oracle JSON Store may be) in back end to support reload/disaster recovery.

2.       Data comes from external applications to cache client via JSON (REST or KAFKA STREAMING)

Let' say, I have Customer in my domain.

Current:

Now if we observe below one,  it has GEODE data model + JSON annotations to full proof schema validations before committing to cache.
It goes into cache as JSON-> PDXINSTANCE via JSON AOP PROXY or JsonFormatter.


INCOMING DATA (REST of KAFKA STREAMING)

GEODE MODEL (What goes into cache)

MONGO GETS (As backend)

{
                "customerId" : "C1",
                "customerName" : " Dharam",
                "address" : {
                                "city" : "Mumbai",
                                "state" : "MH",
                                "line1" : "Something bigger"
                },
                "contactInfo" : {
                                "primaryPhoneNumber" : "+91XXXXXXXXXX",
                                "email" : "c1@hyx.com<ma...@hyx.com>"
                }
}

@Region
class Customer {
                @Id
                @javax.persistence.Id<https://secureweb.jpmchase.net/readonly/http:/javax.persistence.Id>
                @NotBlank
                private String customerId;

                @NotBlank
                private String customerName;

                @Valid
                private ContactInfo contactInfo;
}

class ContactInfo {
                @ContactNumberConstraint
                @NotNull
                private String primaryPhoneNumber;

                @ContactNumberConstraint
                private String secondaryPhoneNumber;

                @Email
                private String email;
}


{
                "customerId" : "C1",
                "customerName" : "Dharam",
                "address" : {
                                "city" : "Mumbai",
                                "state" : "MH",
                                "line1" : "Something bigger"
                },
                "contactInfo" : {
                                "primaryPhoneNumber" : "+91XXXXXXXXXX",
                                "email" : "c1@hyx.com<ma...@hyx.com>"
                }
}



Problem: Time to market for any small/minor changes in schema (Build efforts + Deployment time + User + Automated Testing)

So to avoid that, what if I can define "Dyna Model" which does support "Dynamic JSON schema validation before something enters caching and no code changes required for schema changes"

Suggested Dyna Model

Gain: Anything can be added into customerDetails and PDX already supports multiple versions without any code changes required. Though I am consumed with below as domain class

INCOMING DATA (REST of KAFKA STREAMING)

GEODE MODEL (What goes into cache)

MONGO GETS (As backend)

{
                "customerId" : "C1",
                "customerName" : " Dharam",
                "address" : {
                                "city" : "Mumbai",
                                "state" : "MH",
                                "line1" : "Something bigger"
                },
                "contactInfo" : {
                                "primaryPhoneNumber" : "+91XXXXXXXXXX",
                                "email" : "c1@hyx.com<ma...@hyx.com>"
                }
}

@Region
class Customer {
                @Id
                @javax.persistence.Id<https://secureweb.jpmchase.net/readonly/http:/javax.persistence.Id>
                @NotBlank
                private String customerId;

               @ApplyPdx
               private String customerDetails;
}


1.       So here, @ApplyPdx is by spring-data-geode which will convert json to pdxinstance while storing instance of "Customer" into cache.


2.       customerId maps to KEY constraint in GEODE


3.       customerDetails maps to  VALUE constraint and make JSON DOCUMENT available as value (It's same to incoming data)



4.       Result will be similar to Region<String,PdxInstance> but with above model, Region declaration would still be Region<String,Customer>



Customer customer = Customer
                                                            .withKey("c123")
                                                           .withValue(" {// JSON DATA} ")

customerTemplate.put(customer.getCustomerId(), customer.getCustomerDetails())

customerRepository.save(customer)



{
                "customerId": "C1",
                "customerDetails": {
                                "customerName": "Dharam",
                                "address": {
                                                "city": "Mumbai",
                                                "state": "MH",
                                                "line1": "Something bigger"
                                },
                                "contactInfo": {
                                                "primaryPhoneNumber": "+91XXXXXXXXXX",
                                                "email": "c1@hyx.com<ma...@hyx.com>"
                                }
                }
}


Please share your thoughts as well.

Thanks,
Dharam

This message is confidential and subject to terms at: https://www.jpmorgan.com/emaildisclaimer<https://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.

This message is confidential and subject to terms at: https://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.