Dan and Hitesh - Thank you, this was very informative and exactly what I was looking for. And thank you for clearing up my confusion of PdxSerializable and DataSerializable.
- Jared > On Jan 12, 2017, at 12:06 PM, Hitesh Khamesra <hitesh...@yahoo.com.INVALID> > wrote: > > Jared: > For new(furture) version we have mechanism to deal with old version nodes. > look InternalDistributedMember class's function (fromDataPre_GFE_7_1_0_0). > You can use this mechanism to deal with older version. > > -Hitesh > > > From: Jared Stewart <jstew...@pivotal.io> > To: dev@geode.apache.org > Sent: Thursday, January 12, 2017 10:52 AM > Subject: Strategy for changing fields in a class serialized with PDX > > Cluster configuration [1] is currently serialized with PDX and stored in an > internal region that is replicated on all Locators. I would like to change > the Configuration class from having a Set<String> jarNames to having a > Map<String, byte[]> jarNamesToJarBytes. However, this would create a problem > when a Locator running the new version of the software tries to deserialize > an instance of the previous version of the Configuration class. > > Basically, inside Configuration’s fromData() method, I would like to > determine whether the serialized instance came from a version of the class > with a Set or a version of the class with a Map. However, I don’t see > methods in DataSerializer to check for the existence of a particular field > name or field type. Does anyone know of a strategy that has been used in the > past to make these sort of changes? > > Thank you, > Jared > > > [1] org.apache.geode.management.internal.configuration.domain.Configuration >
