Sign In Register

How can we help you today?

Start a new topic

GameData service missing features

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: - 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.




8 people like this idea

Customer Support/Liam,

Are you saying that the max returned record count for a query is 100, no matter the actual number of results? Is this documented? Is there a way to programmatically determine that more records exist but were not returned? Is it possible to view the next "page" of results with offset/limit parameters?

As far as collection drops, that's surprising and I imagine it's not a widespread issue. Wouldn't it be better to reach out to the offenders than restrict a fundamental DBA operation?


1 person likes this

I'm sorry but implementing a new system, with lack of features from the previous system is not a good thing.

Please resolve this ASAP and maybe enable the old system until the feature set is there.

5 people like this
@Liam, can we have confirmation about the 100 record cursor limit and/or (undocumented) paging mechanisms? That has an impact on the data structure design and general feasability of using the GDS for any kind of data storage.

Hi Lo,

The 100 cursor limit is documented here. To page you would likely need to keep a count of the documents in a data type and use that as a reference for paging if required.



Thanks for pointing that out. It's very hard to notice that since it's mentioned as an aside and located on the page discussing the administrative UI, not the development reference. The querying limitations mentioned in those bullet points should be included in the API reference for queryItems. Notes on consistency behavior and other limits enforced by the GDS should probably have their own preface in the SparkGameDataService reference as well.

It also appears that there is no paging mechanism and that one would need to be created ad-hoc. The MongoDB API had limit/offset modifiers to cursors that would be ideal here.

2 people like this

 I agree that some restrictions cause many problems with providing all required by GDD features. Right now:

1. I can't create custom CMS for editing custom game collections because I just can't query whole collection - missing pagination support and querying whole collection without specifying any indexed key.

2. I can't create new document without providing id. I must create id by hand and do it in way that cause minimal collision chance...

3 people like this

I'm "reviving" this thread because I'm very frustrated with the Game Data experience GameSparks is providing, due to several common problems fellow users have posted here.

You're missing very basic stuff such as introducing how to add indexed items into a collection and/or automatically generate an ID when a new entry is created. Both of them I handled myself--the latter, partially, am facing a collision chance still--but would be pleasant to have things clearer since GameSparks is proprietary.

Furthermore, other things like getting all items of a collection are being a headache. Again, a pretty basic thing which I still don't have a clue on how to do it since there's no pagination or whatsoever.

Could someone, please, point me in the right direction on how to achieve this?

Want to save match information and retrieve it whenever I want but the retrieval thing is just blocking our team to move on.

2 people like this


I second that, automatic id generator as well as knowing the value of count is a must. you can keep a static count variable which changes whenever items are added or removed in a collection, this way there wont be an overhead of calculating count dynamically.

2 people like this

I also have to revive this thread because it seems like we need a way to delete our data in cloud code. I created a bad data type (underscore in data type name). Using the data explorer to drop the data type doesn't work because of the underscore in the name. I'm not able to query for every document in cloud code because the data type has no indexes, and doesn't have a field that could be indexed (only value in the data type is an array). I'm not able to drop the table in cloud code. I think at the very least GameSparks should warn or error when I created the bad data type with the underscore in the name. I am stuck with bad data for every player that I cannot delete.  The warning message in the documentation should also be in a warning color like yellow/orange. It's easy to skim over the blue warning.

2 people like this

For this case I almost always pass additional document field "id" to get at least one indexed element... :)

Login to post a comment