Sign In Register

How can we help you today?

Start a new topic

Fields in JSON stored in GameDataService do not have correct types in CloudCode

Hi,


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:


   

//** Assume this JSON is stored in TEST
{ 
   "one": 1
} 
**//

var test = gds.getItem('PlayerData', 'TEST').document().getData();
typeof(test.one) // "object"

var test2 = { "one": 1 }
typeof(test2.one) // "number" 

   


This makes it near impossible to do any sort of comparison on the data, which is something we do a lot of. For instance:


 

test.one == 1 // false
test2.one == 1 // true



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

Well this aged well...

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


1 person likes this

I've entered a bug related to this months ago with no response.
https://support.gamesparks.net/support/discussions/topics/1000088668

This behaviour violates JS specification standards. It's quite critical.

Yet another problem.


Using hasOwnProperty on objects read from game data service (probably) always fail with error:

TypeError: Cannot find default value for object.

1 person likes this
It's not bizzare at all it's just boolean packed into wrapper object. ;)
Document from game data collection looks more like this:
{
  "flag": new Boolean(false),
  "someNumber": new Number(3.14),
  "evenString": new String("ala ma kota")
}

So yes, we can't use === and !== operators, we can't use it just as simple value and testing value type is also painful.
Reply to Sebastian's reply:
It's even more bizarre.
if (document.flag === false) // will return false.

It seem only string and number is being handled correctly.
And if the document is nested like this:
{
"field": {"childField": value}
}

The object from query result when use with function

object.field.hasOwnProperty("childField")

 will result in an error as object.field is not treated like a json object anymore.

// Some document in collection

{

  "flag": flase

}


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.


1 person likes this

I just want to say this is still not fixed. And I don't know how to extract data from this.

Hi there,


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


Thanks

Hi Jason,


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.


Regards,

Liam

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. 

Login to post a comment