In geary-1.0 we had the concept of migrating entities when the definition updated. This was put in place to prevent existing items breaking on an upgrade.
(see https://github.com/MineInAbyss/geary-1.0/blob/ebcfaa4deed2f28c523db9384b16375282eac344/src/main/java/com/mineinabyss/geary/ecs/entity/migration/GearyEntityMigration.java#L11)
Something to support the same use case is necessary for Geary.
Basic outline:
- Attach a (non static, persistent) component to every entity containing a simple version number for each component. (if version #0 do not serialize to keep component from bloating)
- Component providers provide a migration specific to component whenever a component needs to change. Migration handles updating from serialized form (because the class definition has probably changed). This might be a bit tricky.
- On loading an entity for the first time on a server restart (be it from PDC, or what have you) compare the version number for each component with the version number of the latest migration.
- On mismatch apply all registered migrations in order starting from the first one with a higher version #.
In geary-1.0 we had the concept of migrating entities when the definition updated. This was put in place to prevent existing items breaking on an upgrade.
(see https://github.com/MineInAbyss/geary-1.0/blob/ebcfaa4deed2f28c523db9384b16375282eac344/src/main/java/com/mineinabyss/geary/ecs/entity/migration/GearyEntityMigration.java#L11)
Something to support the same use case is necessary for Geary.
Basic outline: