Closed zepumph closed 1 year ago
When migrating from 1.5-> 1.7
Assertion failed: migration rules must handle all elements that converted to be LinkedElementIO.
gravityAndOrbits.modelScreen.nameProperty
gravityAndOrbits.toScaleScreen.nameProperty
gravityAndOrbits.toScaleScreen.view.playAreaNode.starPlanetSceneView.measuringTapeNode.visibleProperty
gravityAndOrbits.toScaleScreen.view.playAreaNode.starPlanetMoonSceneView.measuringTapeNode.visibleProperty
gravityAndOrbits.toScaleScreen.view.playAreaNode.planetMoonSceneView.measuringTapeNode.visibleProperty
gravityAndOrbits.toScaleScreen.view.playAreaNode.planetSatelliteSceneView.measuringTapeNode.visibleProperty
We got to a pretty good spot here, making some progress. We ran out of time with the fact that
gravityAndOrbits.modelScreen.model.starPlanetScene.clock.timeProperty
changed from NumberPropertyIO -> RewindablePropertyIO, and so no longer has a numberType
attribute.
Assertion failed: stateObject provided a key that is not in the schema: numberType
@samreid and I would like to use this opportunity to see if we can improve how new migration rule classes are created. We will touch base tomorrow.
Here is a working patch that fixes the Gravity and Orbits 1.5 -> 1.7 problem for the NumberProperty => RewindableProperty.
I tried to keep the following objectives:
IOTypeStateAttributeDelete
without overcomplicating itThere are other ways to do this, we should discuss.
Lots of good progress today expanding on @samreid's patch above. We created IOTypeChange, with hard coded mappings inside for how to handle each possible change. In the future we may want to factor these out, but the boilerplate to do so at this time didn't seem worth it.
Then! We were able to make a migration rule checker that asserts out whenever it finds a phetioID that has had a type change without being "handled" by a migration rule. This helped find multiple things that were sliding through the cracks before, though none were causing any trouble except for one in gravity and orbits (hence why it was failing on CT because it because a RewindableProperty).
Still to do and discuss with @samreid:
EnumerationToStringUnionValue
. Hey! That's a type change!! I think that would be a good candidate for moving into IOTypeChange, but didn't feel confident enough during today's session.I'll move the main work of IOTypeChange to a method documented that we need to be careful not to change existing or legacy functionality.
From today's discussion:
All is done except:
Tagging https://github.com/phetsims/phet-io/issues/1960