Migration Integrity
jkeon opened this issue · comments
Building off of #232
- Integrity.
- As we talked about, we should be able to build a lookup of all Entity references before the Migration occurs. After the Migration, we can run through that lookup and see if anything of our references were broken.
- Either A) We referred to something that left us behind.
- Or B) We referred to something that we left behind.
- We can then alert the developer who didn't clean up before the migration.
If you have a sec to quickly jot down a high level potential approach that will help get this done when we pick this up some day way down the road.
Sure!
Most likely as part of the reflection pass at the beginning with the other migration functionality we'll scan the types and nested types and nested collections to find where any Entity
references could be hiding and we'll build a map of that.
Then before actually migrating, we'll run a job to collect the TaskDriver data and EntityPersistentData that has Entity references and we'll store what we were referencing.
If we were referencing Entity.Null, that's all good, just means the slot was empty.
If we were referencing a real Entity, then we'll want to check to make sure that:
- A) If we moved, who we were referencing moved too and is now a valid entity in the new world.
- B) If our referenced entity moved and we didn't, that's a problem.
We actually do the move, and then we collect everything that stayed in the old world and find any breaks and we collect everything in the new world and find any breaks there.
High level architecture should look like a pre and post job on either side of the actual move. One to build the current state, and then the post to check it.