eXtreme data format (XDF) allows for
class evolution. With class evolution, you can evolve the class definitions
that are used in the data grid without affecting older applications
that are using previous versions of the class. These older classes
are accessing data in the same map as the new applications.
Overview
Class evolution is a further extension
of the identification of classes and fields that determine whether
two types are compatible enough to function together. Classes can
function together when one of the classes has fewer fields than the
other class. The following user scenarios are designed into the XDF
implementation :
- Multiple versions of the same object class
- In this scenario, you have a map in a sales application that is
used tracking customers. This map has two different interfaces. One
interface is for the web purchases. The second interface is for the
phone purchases. In version 2 of this sales application, you decide
to give discounts to web shoppers based on their purchasing habits.
This discount is stored with the Customer object. The phone sales
employees are still using version 1 of the application, which is unaware
of the new discount field in the web version. You want Customer objects
from version 2 of the application to work with Customer objects that
were created with the version 1 application and vice versa.
- Multiple versions of a different object class
- In this scenario, you have a sales application that is written
in Java™ that keeps a map of
Customer objects. You also have another application that is written
in C# and is used to manage the inventory in the warehouse and ship
goods to customers. These classes are currently compatible based
on the names of the classes, fields, and types. In your Java sales application, you want to add an option
to the Customer record to associate the sales person with a customer
account. However, you do not want to update the warehouse application
to store this field because it is not needed in the warehouse.
- Multiple incompatible versions of the same class
- In this scenario, your sales and inventory applications both contain
a Customer object. The inventory application uses an ID field that
is a string and the sales application uses an ID field that is an
integer. These types are not compatible. As a result, the objects
are probably not stored in the same map. The objects must be handled
by the XDF serialization and treated as two distinct types. While
this scenario is not really class evolution, it is a consideration
that must be part of your overall application design.
Determination for evolution
XDF attempts to
evolve a class when the class names match and the field names do not
have conflicting types. Using the ClassAlias and FieldAlias annotations
are useful when you are trying to match classes between C# and Java applications where the names
of the classes or fields are slightly different. You can put these
annotations on either the Java and
C# application, or both. However, the lookup for the class in the Java application can be less efficient
than defining the ClassAlias on the C# application. For more information
about the ClassAlias and FieldAlias annotations, see
ClassAlias and FieldAlias annotations
The effect of missing fields in serialized data
The
constructor of the class is not invoked during deserialization, so
any missing fields have a default that is assigned to it based on
the language. The application that is adding new fields must be able
to detect the missing fields and react when an older version of class
is retrieved.
Updating the data is the only way for older applications
to keep the newer fields
An application might run a fetch
operation and update the map with an older version of the class that
is missing some fields in the serialized value from the client. The
server then merges the values on the server and determines whether
any fields in the original version are merged into the new record.
If an application runs a fetch operation, and then removes and inserts
an entry, the fields from the original value are lost.
Merging capabilities
Objects within an array
or collection are not merged by XDF. It is not always clear whether
an update to an array or collection is intended to change the elements
of that array or the type. If a merge occurs based on positioning,
when an entry in the array is moved, XDF might merge fields that are
not intended to be associated. As a result, XDF does not attempt
to merge the contents of arrays or collections. However, if you add
an array in a newer version of a class definition, the array gets
merged back into the previous version of the class.