Avoiding having to clear the object store

Networking & Multiplayer
#1

The SGS stores Managed Object in serialized form in the ObjectStore.

For this reason, changes to Managed Object’s defining class that Serialization considers an “incompatible change” will result in exceptions on attempts to fetch the object. The only current remedy for this situation is to clear the entire object store.

Below are some rules of thumb for avoiding incompatible changes:

  • Always give your Class a hard-coded SerialVersionUID
    Without this, many more kinds of changes will be incompatible.
  • Do not change a Managed Object from Serializable to Externalizble, or vice versa.
    This is an incompatible change
  • Do not change a Managed Object froma non-enum classto an enum class, or vice versa
    This is also an incompatible change
  • Do not change the unqualified name of the class
    Yes, this means you cant refactor the class into a new package. The system has no way of knowing if its really the same class or a different one with the same unqualified class name.
  • Do not change the type of a primitive field to a non-primitive or different
    primitive type, or vice versa
    If you need to change the primitive type of a field, declare a new field for it.
#2

How to refactor FQDN without messing up the ObjectStore

This is a bit ugly but SHOULD work…

(1) Create your new class in its new package without deleting the old one.
(2) Add a “writeReplace” method to the old one that writes the new one.

This will cause the system to replace the old ones with the new ones on the next change to the data.

Managing ManagedObjects