model.save best practices

Question

Hi All,

Just a quick question here about Sidecar's save() function.

I'm effectively doing the following via Sidecar:

var accountBean = app.data.createBean("Accounts", { id: this.model.get("billing_account_id") });

accountBean.fetch();

I then (assuming the conditions are correct), want to update one field, and report success to the user.

I've seen two ways of doing this, and I wondered which was considered the "best practice".

The most frequently seen Sugar way (passing the whole model back through)

accountBean.set("account_type","Customer");
accountBean.save({ {},{
    success : function(account){
        //code here
    }
}

Or the way documented on backbone.js where only changed properties are sent through:

accountBean.save({ {"account_type":"Customer"},{
    success : function(account){
        //code here
    }
}

Is there any benefit to doing either way? Any big problems with either way?

Richard Coleman · Accepted Answer

So the first pattern, using set() is used in Sugar code a lot because a user might make many updates to a model prior to running a save(). For example, if you were updating a record view one field at a time then there are change events, field validation and formatting, etc., that all get triggered in the mean time before the user finally hits the "save" button. I know there are some attributes on the model that keep track of the fields that were originally fetched from server, the changed attributes, etc. So it is possible to determine what changes have been made and only send back the changed fields. It may be that in some places we are conservative and send everything back.

The second pattern is fine so long as you aren't chaining a bunch of these requests together. Each of these would generate a full HTTP request round trip that results in a SugarBean save event on backend which could trigger other workflows or logic hooks. Chaining a bunch of save events on a SugarBean can be pretty expensive depending on the circumstances. Not to mention that browsers will limit the # of open HTTP connections a page is allowed to have.