User Values should be properly Persisted

(Incomplete Feature, To be Fixed , Priority: Critical, Test Status: No automated tests yet , Reported By Justin du Coeur, )
User Values, Internals
Summary: This is basically a marker so we don't lose track of this half-completed Epic, which I started and then realized wasn't critical-path yet.
Here's the deal.
Currently, User Values are managed in the old MySQL way. They are functional but grody, and don't fit the new architecture well; they should get ported.
After much soul-searching, I've concluded that in the new Cassandra world, we should actually denormalize User Values. I don't come to this lightly, but I think it's correct. The thing is, the "user" view and "thing" view are used very differently, and trying to keep them normalized means that we address potentially lethal scaling issues -- when you multiply the number of potential Things in a Space by the number of potential Users (especially in light of the recent change to permit Public User Values), this gets nasty.
So we're looking at two distinct PersistentActors. On the one hand, there is the new UserSpaceSession. This implements the UserValueSessionCore, which encapsulates the notion of this particular User's UserValues in this Space. As in the old world, it is responsible for enhancing the SpaceState with those UserValues; unlike the old world, there is no longer a MySQL UserValuePersister involved.
On the other hand, there will be a new ThingUserValuesActor. This PersistentActor will encapsulate the UserValues that have been assigned to this specific Thing. It is slaved under the UserSpaceSession -- when the UserSpaceSession gets a UV change, it forwards that to the ThingUserValuesActor, which is basically just a dumb bundle of state.
All of this is about 1/3 written at this point. The previous version has been renamed OldUserSpaceSession, to make namespace room for the new Actor. The new UserValueSessionCore (under querki.uservalues) is partly written, and the beginnings of the new UserSpaceSession has been built around it. We still need to:
  • Finish UserValueSessionCore. In particular, the SpaceState enhancement code needs to go in there.
  • Write unit tests for UserValueSessionCore.
  • Add a config flag to turn on the new version of UV.
  • Flesh out the new UserSpaceSession with all the other stuff from OldUserSpaceSession. I suspect this Actor will mostly be glue for a couple of distinct traits.
  • Create the persistent ThingUserValuesActor.
  • Rewrite the functions in UserValuesEcot to match the new reality. When we create the enhanced SpaceState, we should probably stuff this user's UserValues into the cache, so that _thingValues can just work directly, but _userValues will need to become a request to the new ThingUserValuesActor. Note that _userValues will also need to be enhanced with a roundtrip to the IdentityCache to fetch the needed Identities, since we are now only storing the IdentityId.
  • Come up with a transition scheme. I believe this will involve adding a persisted flag to the Space itself, saying that we've done this evolution. Really, this is time to figure out the new Evolution scheme for the new world, which will be all about persisted flags rather than database transitions. (Or possibly we just keep using the old Space Version number? Might work.)