Everything is working like a charm so I’m now looking to leverage the storage API to record historical data for the user. My main two questions first:
- If two separate clients write to the same collection/key pair, does the second over-write the first or are they separate due to the different user_id?
- Can I retrieve all objects in a collection instead of providing specific keys? If so and the above is the second option, can a client retrieve only objects owned by themself?
For example, I would like a collection called “matchResults” and (at the end of the match) have each user store their match results in a key equal to the match ID. Then, a client could retrieve all their match results for a match history feature and I could run statistics over the data in value. I would also like to go a bit further and have the server store data about the match configuration in a “matches” collection, again keyed by the match ID from which I could retrieve info about the match that isn’t player specific like its date, label etc
@Shikadi I’m glad you’re happy with the tech so far. I’ll answer each of your questions inline.
If two separate clients write to the same collection/key pair, does the second over-write the first or are they separate due to the different user_id?
If two game clients write to a storage object keyed on the collection+key pair they will each have their own storage object because the object is scoped to the user (because it was written by the game client via the main API). If you want to have storage objects that multiple users can write into you should use an RPC function and create the object through server-side logic. This gives you total control to guard access to the data.
Can I retrieve all objects in a collection instead of providing specific keys? If so and the above is the second option, can a client retrieve only objects owned by themself?
Yes you can list objects in a collection. There’s a method for each of the SDKs which is specifically designed for this use case:
When a user lists objects in a collection they’ll receive those which are marked with public read as well as objects which are their own. They will not be able to list objects which are marked no read or belong to other users (marked with private read).
All of the use case you describe above is a perfect fit for the storage engine API. It was specifically designed for this kind of game data which needs to be shared in part to all players or protected in some way privately on the server to be read via an RPC function.
Hope this helps.