This chapter describes evolvable classes.

Externalizable classes that implement the Evolvable interface are the Windchill classes that can be serialized into BLOB columns in the database. As the persistent structure of these classes changes, action may be required to maintain compatibility with previous versions that have been serialized into the database.

Any modeled class that is intended to support being serialized into a BLOB database column must implement the Evolvable interface. Once Evolvable is implemented, the owner of the class must manage its compatibility from version to version.

The Persistent Data Service (PDS) will report any classes being serialized into the database that implement the NetFactor interface and not the Evolvable interface. This allows third party classes, such as Vectors, Hashtables, and so on, to be serialized into the database. This also allows modeled classes that do not implement NetFactor to be serialized into the database; however, we do not recommend this practice because it leaves the class exposed to serious data migration problems.

The best way to specify that a modeled class will implement the Evolvable interface is to set the Serializable property for the class to Evolvable.

The Persistent Data Service (PDS) will restrict persisting serialized objects of PTC classes that do not have a serialVersionUID. If such objects are stored in a database, PDS will throw wt.pds.NotEvolvableException. To avoid this exception, serialVersionUID is added to all the PTC’s serializable and externalizable classes.

Serialized objects of non-PTC classes can be restricted from persisting by the customer by setting the wt.pds.customNonEvolvableClassAction property in the wt.properties file to exception. The default value of this property is none. This property can have the following possible values: none, warning, traceback, and exception.

The generated externalization code reads and writes a data stream according to the following order, with field values for each class ordered alphabetically:

To maintain externalization compatibility of a class from version to version, it is most important to understand the resulting stream layout for each version of a class. When the persistent signature of a class is being changed significantly, it may be helpful to map out the stream format for each version, in order to understand clearly what is necessary to read a previous version of the stream.

Beyond the fundamental understanding of the stream format, points in the following sections provide guidance concerning when and what kind of manual intervention is necessary to maintain compatibility.