We have a fair deal of game and user specific data saved in the api.Account.User.Metadata field and it works fine. The data is updated, refreshed and saved as needed when something happens. However, the data can also be modified in the normal web console where it’s presented as a JSON tree. Editing and saving the data there does work, but it gives us problems in case the user is already loaded/cached in our Go module. The module doesn’t know the data was refreshed on disk and will happily overwrite it next time it saves.
Is there some event or mechanism where our module would be made aware of these changes? There’s the UpdateAccount event that we already use to refresh the user’s display name, but it’s not called in this case even though the user’s account was updated. Is the web console somehow special and avoids all events or is there some better way? The console could be useful even in production to do some occasional tweak to some user’s data, but not if it causes data loss.
There is no event available to be notified of changes made to user metadata via the Nakama Web Console in your Go server runtime code.
Depending on how often changes are made via the console, you could try and fetch the latest user metadata and refresh your cached version of it first before attempting to modify it. Though this would never 100% guarantee changes haven’t been made in the interim.
If you need full protection from concurrent data edits I would advise migrating the relevant data from user metadata over to the storage engine, where you can make use of conditional writes (Nakama: Collections | Heroic Labs Documentation) to ensure data consistency.
We’re not looking for a 100% concurrent editing safe solution, although one would of course be nice. This need is mainly for fixing some data for some users that have lost something or have had some crash leading to them not getting something they should have gotten. Basically for fixing errors. So a mechanism where our module just got a notification that a user id has been updated would be fine and our internal cache could then reload the data. Would have been nice to not have to do an own dashboard for simple stuff like this.
The storage engine seems to not be too suited for user specific meta data that is updated all the time? We do use it for some less often needed data such as purchase logs etc.
I’m keen to know why you think the storage engine would be less suited than user metadata. Can I ask what kind of data it is you are storing and where it is used in your game?
Also, you mention items are being lost. Are you able to identify when and where these crashes / glitches occur? If they are happening frequently it may be worth tackling the underlying issue causing these item losses.
You can of course use the Nakama Console to manually edit metadata and storage items, but it is not intended to trigger pushes/notifications to connected clients notifying them that the data has been changed. Therefore this would need to be managed in your client to ensure stale data is not being presented.
I didn’t mean that list data would be something caused by Nakama. I meant things that we somehow lose ourselves due to bugs, crashes or force majeure. There will be cases where something like network loss means a user will not get a reward or similar and it’s then useful to be able to just do a quick data edit and keep the user happy. But as this will lead to more data inconsistencies we will have to create some own dashboard to handle fixes like these.
Saving data in the storage engine is clumsy to say the least. It may be efficient or safe but it makes my head hurt every time I have to use it. The metadata is easier to use and at least the documentation back then suggested that this was the way to go.