Updating sObject from getRecord method forces update of all fields not fields set

[askhogan]

I experienced a strange workflow issue today when reading the documentation to nforce and the expected result I got. I can see now after digging into code and setting breakpoints what occurred and why, I am just hoping the maintainers will edit the README to spell out potential problems for users.

My use case was that I was trying to update a salesforce record. I read the update method and found out it required an sObject. I have a method that uses the getRecord method and returns an sObject and then calls another function. With the other function I set three parameters and then call update on that sObject.

When I ran the update after setting only 3 fields through the .set method, I got a really strange permissions error result from nforce, that I was trying to set fields that I were never updated via set methods. I discovered that if you take the object from getRecord and set even 1 field on the returned sObject for update, you are telling nforce to try and update every field. This is problematic, because by default Salesforce restricts several fields from being updated, even with admin level users. So this update will usually fail.

I cannot determine what a good refactor would be to prevent this. I do believe that maintainers should spell this out in the documentation, by saying next to update record, that if you already have an sObject and just want to update a few fields, it is much better to create a brand new task and set the id.

[askhogan]

Looking at the documents more, the info in your docs is not consistent. For example

Querying and updating records is super easy. nforce wraps API-queried records in a special object. The object caches field updates that you make to the record and allows you to pass the record directly into the update method without having to scrub out the unchanged fields. In the example below, only the Name and Industry fields will be sent in the update call despite the fact that the query returned other fields such as BillingCity and CreatedDate.

So it seems this is actually a bug. Because getRecord does not behave like query

[kevinohara80]

I can take a look at this tomorrow. It's likely a bug from the refactor to the 0.8 beta.

On Thu, Oct 2, 2014 at 9:32 PM, Patrick Hogan notifications@github.com
wrote:

Looking at the documents more, the info in your docs is not consistent. For example
Querying and updating records is super easy. nforce wraps API-queried records in a special object. The object caches field updates that you make to the record and allows you to pass the record directly into the update method without having to scrub out the unchanged fields. In the example below, only the Name and Industry fields will be sent in the update call despite the fact that the query returned other fields such as BillingCity and CreatedDate.

So it seems this is actually a bug. Because getRecord does not behave like query

Reply to this email directly or view it on GitHub:
#68 (comment)

[kevinohara80]

This was indeed a bug from the refactor to 0.8. This actually effects query too. What was happening was the initialization of a new SObject was setting all of the fields to changed status as that's the normal behavior when a user creates a new SObject. There was a _reset method that was introduced in the new API that needed to be called after receiving a queried sobject that resets the changed cache. That's now happening for query and getRecord.

You'll see this in 0.9.0 tonight.

[kevinohara80]

0.9.0 is now available