I’ve got an object type that I’ve held off on migrating for a long time, but now finally need to bite the bullet on so that I can do more with Automations live monitoring.
That said, there is a lot of usage of this object type across a whole range of Workshop modules, actions, functions, etc and I’m trying to make sure nothing will break.
The migration wizard is very reassuring with the soak time and rollback support, so my main hesitation is the “incompatible usage” metric - the chart indicates a small number of ongoing incompatible reads, but drilling in just gets me to the level of an individual resouarce (i.e. Workshop module) and doesn’t give any indication about what that usage represents.
The docs only provide examples for non-breaking usage related to hitting API endpoints directly, but all this activity is primarily driven by Workshop, which I imagine should all be ok?
Are these likely false positives? Is there a way to be more certain or investigate further?
I think the key thing that could break is if you have any Queries or API calls being made to the Phonograph table that’s used in V1 Storage. If all your interactions are from Ontology aware applications (like those in your screenshot), or via the Object API, then I think you’re OK.
As a counter example this is the usage from an Object I manage which is OSv1 and has known incompatible usage:
In this case Slate (via Query), and Forms are not compatible are are things we have to change before migration. (Slate can also query via the Platform tab, but I assume that doesn’t appear as an ‘incompatible’ usage.)
‘python-requests’ is a little strange, as we had examples where there appeared to be some kind of ‘background noise’ of such requests happening on almost all OSv1 objects, and we didn’t know where it came from, and our support team said it was safe to ignore.
I also don’t know what incompatible requests Workshop could be making, as you can’t interact with Phonograph there, and it does everything through the object abstraction.
If your object is editable, perhaps first change the ‘Only allow edits via actions’ option under ‘Datasources’, and see if that leads to problems. That should at least reveal (possibly via shouting) if anyone is editing the phonograph table not via an Action, and is very easy to change back.
Thanks @green - I think we tracked this down to using the legacy Edit History widget in Workshop, which makes calls to Phonograph instead of through OSS.
