Skip to main content

According to this, skuid.model.updateData() has been deprecated.

Works in version 11.1.7 without issue.

The proposed workaround is to use skuid.model.Model.update(), but this isn’t great as it’s for just the one model at a time. I have this code that would be faster since it’s querying multiple models at one time. There’s also good reason to query at the same. Take cloning as an example. Problematic without updateData() when the models are set to clone always.


var params = argumentsr0],<br> FirstModel = skuid.$M('FirstModel'), SecondModel = skuid.$M('SecondModel'), Entities = skuid.$M('Entities'), models = oFirstModel,SecondModel], $ = skuid.$; var dfd = $.Deferred(); function updateModels(){ $.when(skuid.model.updateData(models)) .done(function(){ if (SecondModel.data.length){ Entities.adoptRows(SecondModel.getRows()); updateModels(); } else { dfd.resolve(); } dfd.resolve(); }) .fail(function(){ dfd.reject(); }); } updateModels(); return dfd.promise();


Did I miss something?

Thanks for bringing this to us Pat to make us aware. I’m going to turn this into an idea so that future releases of Skuid can take this into consideration.


It says it’s deprecated, but it still works as is right now. So … it’s planned to be removed?


Deprecated means that it won’t be maintained to see if it continues to work. It works now, but we won’t promise it’ll work in the future. It’s not supported.


We noticed this, panicked, then realized it was still functioning.  Looking at the list, I think there is a LOT on there that we are using.  That feels like a risk that we probably need to address.

To help us make that decision, can you let us know the reasoning behind all these functions being deprecated?


Agree completely.


Well … since it’s already working as is, can you just continue to support it? It’s seemingly one of the more used function calls.


Usually something is deprecated because we somehow lose the ability to continue to support it. Usually there is a component of ‘this is now out of our control’ so we switch to something that is in our control.


We’d really like to understand what ability was lost.

For funsies, I ran a query in our Production org finding PAGES (not number of usages) of:

skuid.model.updateData : 68 pages affected
skuid.model.save: 29 pages affected
skuid.ui.fieldRenderers: 38 pages affected

I just ran these three.  So this adds up to a ton of re-work for us.  Hence asking the why.



I’ve asked our documentation team about this. It sounds like a great component to add to the documentation page. Thank you for suggesting this!


I don’t want to do this search my system and my clients systems. 100’s of pages for sure.


I have code from Brooklyn and earlier that uses updateDate(callback). It breaks severely in Millau (11.1.6), and I’ve been told I should first upgrade the deprecated function. My call is 


skuid.model.getModel("myModel").updateData( function(result)&nbsp;<br> {&nbsp;<br> myFunction(result)&nbsp;<br> }&nbsp;<br> );<br>

Is this the deprecated updateData() or not?
If it is the deprecated API, what is the supported alternative? I’ve looked at the documentation, and I’ve read multiple forum posts, and I do not have an answer.
Thanks!


I don’t think it’s the same function. You’re using skuid.model.Model.updateData(). This is still supported. skuid.model.updateData() has been deprecated.


Hmmmm … My new question is this. How is Skuid performing it’s Skuid actions for the following?


MODEL SAVE



MODEL CANCEL



I’ve always assumed that the engineers make use of the same calls to enable page builder functionality.


^^^ bump ^^^


^^^ bump ^^^


Official response: the following methods are NOT being deprecated, and will continue to work as before in future releases. You may freely and safely continue to use the following methods, they are supported and will continue to work in future releases:

- skuid.model.cancel()
- skuid.model.updateData()
- skuid.model.load()
- skuid.model.save()

These are all still supported and will continue to work as expected in future releases.

We will be adjusting the documentation to correct this misunderstanding, and we apologize for the confusion and alarm that this has caused. We will be removing these methods from the deprecation list in that document.


Woot woot!