I should note that the problem really comes into play when trying to compare data on two different items from the GameDataServices. Since properties are seen as objects, two properties won't equal the same even if they have the same value.
I've worked around this issue by using parseInt and toString, but that feels like a rather bad solution.
Thanks for raising this. We've got it in our backlog and will be addressing it in an upcoming sprint. I'll be in touch when it has been released.
This issue is also happening on our side, we r saving null values for string while getting them 0 as integer on our C# unity app. which in turn is not letting our Json.net deserialise the data and throwing errors.
When can we expect this fix?
Its very very important for us
I just want to say this is still not fixed. And I don't know how to extract data from this.
// Some document in collection
Booleans are more painfull.
if (document.flag) // is always true
if (document.flag == true) // there we have correct answer...
Fortunately numbers are automaticlly unpacked in typical use case, that means numerical calculations, but still if (Object(0)) will return always true.
will result in an error as object.field is not treated like a json object anymore.
Yet another problem.
Using hasOwnProperty on objects read from game data service (probably) always fail with error:
TypeError: Cannot find default value for object.
I've entered a bug related to this months ago with no response.
This behaviour violates JS specification standards. It's quite critical.
I have been fighting with the boolean value in my data structure for days, spent days finding where is the problem until i was debuging in the harness and found that "false is actually true" situation, I could not believe that at that moment, since it never happens in my coding life. I am trying refactoring all my bool types into numbers or strings...
Well this aged well...
I've migrated over to using GameDataService, however I've found what is a pretty critical bug for me. It seems the data types of fields on JSON stored in GDS are not the correct types within Cloud Code. They're all treated as 'object'. Here's what I mean:
This makes it near impossible to do any sort of comparison on the data, which is something we do a lot of. For instance:
This also applies to strings when using strict (===) comparison.
This seems like a pretty major bug to me, but maybe there's something I'm missing?
3 people have this problem