Finally, there is the matter of invoking the real Create-Read-Update-Destroy (CRUD) actions on the data, which will ultimately be performed in a remote data store. We have already seen the busy states while reading data, so let's look at the additional busy states while creating, updating, and destroying data.

As we can see from the previous figure, all three of these processes are started using the commitRecord method of the store. As we've seen before, when calling commitRecord, we pass in either the record type and ID or the store key. But we can pass a parameter's object too, which can be used to pass information to the data source adaptor about how the commit should be handled.

For example:

MyApp.store.destroyRecord(MyApp.Calendar, aCalendar.get('id')); 

// Commit the change and pass online/offline information through to the adaptor
MyApp.store.commitRecord(MyApp.Calendar, aCalendar.get('id'), null, {
  // We will target different remote stores depending on if we are online or not.
  target: SC.device.get('isOffline') ? 'offlineDataStore' : 'liveDataStore'
});

console.log(aCalendar.toString());
// > MyApp.Calendar({guid: work-calendar, title: Work}) BUSY_DESTROYING

We can commit each record individually as you've come to expect the presence of the commitRecords method for committing multiple records at once. However, what is important to know is that if we don't need to pass any arguments to commitRecords, it will instead, commit all the records in the store that are in an unsynchronized state (that is, READY_NEW, READY_DIRTY, or DESTROYED_DIRTY).

This brings us to the question of what happens after we commit records. As we touched upon this when we first introduced the SproutCore data store, the store is meant to work with a remote data adaptor, which transforms serialized data from a remote data source into data hashes for the store to use and vice versa. Therefore, calling commitRecords causes the store to ask its data source adaptor to actually perform the synchronization by communicating with the remote data source.

There is an amendment to this. We can actually chain stores together in order to queue up a number of changes inside a chained or nested store that is separate from the main store. In this way, we can modify a record temporarily without affecting the rest of the application. If we decide to throw the edits away, we can simply discard all the changes in the nested store and nothing will be changed in the main store. But if we want to keep the changes, we can commit them back up to the next store in the chain. Only when the changes are committed back to the root store will they actually be synchronized using a remote data source.