Sign In Register

How can we help you today?

Start a new topic

Field Update Operators with new Data Typs

With the new Data Types, I know how to create, get, and delete documents. But how do you update the documents like we used to with the runtime collections?


I used to use $set, $inc, and other stuff like that a lot. What's the best practice for selective updating and modifying of the new Data Types?


3 people have this question

I did notice the withAtomicIncrements function in the SparkDataItemPersistor docs. Is there an example of how to use this as well?

Also if anyone is interested in my current solutions I'm using this function

 

function UpdateDocument(dataType, id, document) {

    var entryObject = GetAPI().getItem(dataType, id);
    
    //If error attempting to retrieve entry
    if (entryObject.error()) {
        
        ErrorAndExit(entryObject.error());
        
    } else {
            
        //Get entry
        var entry = entryObject.document();
        
        //Access Data
        var data = entry.getData();
        
        for (var key in document) 
            data.data[key] = document[key];
    
        //Persist and return any errors
        var status = entry.persistor().persist().error();
    
        //If there are errors the entry would not persist and we can act on that information
        if (status) ErrorAndExit(status);
        
    }
    
}

 The downside is I need to add a better way to handle updating large arrays of data. Like if I added one entry to a large array (or deleted one), I'd have to send the ENTIRE array to update it within the data type. I'll probably add another field to handle increments later unless I get a better way to handle this with GameSpark's API.

I appreciate that you found how to save data. I couldn't seem to figure it out. I wrote a comment on the new system on how unintuitive this new system is.


I also agree. I'll start by saying this. When I first started with GS, MongoDB was new to me. So I used the runtime player data storage wrong. I would load the entire document. make a tiny change and save the entire document. I think this is why GS introduced the new system because it's similar to client development where users are manipulating classes whole. However, after a few race conditions, I learned that not only was this wrong, it's very bad practice. So I started using $set/$inc/$push etc. I've also started developing tools around the MongoDB concept. However, now it doesn't work that way my tools are less useful.


So far am not digging the new system. Although I think it's easier for newer devs to use if documentation was more clear, I also think it continues bad practices of server development.


I would really like to opt back into the runtime variation. 


Your history is almost exactly the same as mine so I definitely empathize.

Login to post a comment