Hi GS Support,
As you introduced GameData service and the runtime collection became obsolete, we miss lots of features, which slows development and maybe forces us to use different backend.
Geo features were mentioned here: https://support.gamesparks.net/support/discussions/topics/1000087790 - Geospatial queries with radius, which we use to determine location of places/players around the world.
GetItem() method in cloud code - Currently it supports only search by Id, what if I want to use some custom field as it is in findOne()? This one can be workarounded by queryItems(), but in my opinion, this is ineffective.
Random id when creating new item - You need to specify id, would be nice to have another method without id parameter, so it will generate random one as Mongo did that before, this also can be workarounded and pray that random generator is random enough + add few checks, another ineffective one.
Update queries - Why I would fetch the whole document to make single value change and push the whole document in? In runtime collections I could type update query to change it without fetching whole document, this would be cool to have it.
Atomicity - When two players changed single document, Mongo locked it and then unlock and executed next query. However the persistor with withVersionCheck() only returns false, there should be more documentation how it behaves... if it handles itself (waits), or this should be looped in some cycle - again fetch data, make changes etc... until it will return true.
Fetch only needed fields - In Mongo query, you can specify which fields to return, this was great feature.
Yes, I know some of them are mirror, but I definitely like the effectivity I can achieve and have more control etc...
Hopefully next release will extend this new api as the idea is not bad, but the api feels kinda unfinished.
I feel grateful to be grandfathered in the old system. I keep looking at the new system to see how easy it would be to port over...
Drew, looking forward to seeing continued feedback from you and others. I'm one of the new users Dylan mentioned and don't exactly find the current setup intuitive, ie, no count / length for a data type; I'd assumed this was for performance reasons.
I'd previously tried PlayFab and found while it was step into it wouldn't scale for even some of the simpler features i was trying to implement (like a global marketplace). I've only been playing with GameSparks for a couple of days and am finding it (seemingly) much more powerful + flexible, I'd assumed with the usability tradeoff. If your performance tests are showing worse numbers that is a bit troubling... what conditions / operations were you testing?
Dear support, in your previous answer you did not mention if the Geo features (geo spatial indexes) are going to be implemented soon or not. This is a major break point for us that prevents from switching to the (new) Game Data Types feature.
Can you give feedback on the missing features in this ticket when we can expect some improvements ?
I don't know if it's been said before, but the entire GDS API looks like a subset of Amazon's DynamoDB. I get this sense from the notations used for data typing, index limitations, and other little bits here and there. Amazon's acquisition may or may not be coincidental to that integration. At very least, it was probably seen as a cost management decision for the original team.
If any of that is true, DynamoDB offers very little in the way of built-in aggregate functions and there are no geospatial data types.
Since there have been no blog posts since last July and the Twitter feed is essentially a recycled loop of tutorial links, I'm guessing very few resources have been applied to GS since acquisition. As with many aspects of the game data API it looks like we're left to roll our own solution with an incomplete framework.