Dot walk VS .setValue()

[bonsai]

I'm wondering which of the two methods below I should use to update a field.

I think they have the same effect, but which one is recommended?

I don't fully understand the specifications of dot walk, but if it is implicitly converted to "setValue", I thought that using "setValue" would put less strain on the system.

1 

current.u_field_1 ="test";
current.update();

2

current.setValue("u_field_1","test");
current.update();

[Simon Christens · Accepted solution]

Hi,

In general theres not much difference between setting a field either way.

My personal experience though says that its more consistent to use .setValue() than using .field = something because not all fields are strings and you can risk that the field is not set if theres a mismatch between for field type and input type.

With that in mind when updating comments and work_notes setValue doesnt work so in those cases .comments or .work_notes needs to be populated with "dot-walk".

https://www.servicenow.com/community/developer-forum/how-to-populate-additional-comments-with-value-... 

Hope it clarifies a bit 🙂

[Jim Coyne · Accepted solution]

Just wanted to clear something up here: dot-walking is about referencing a different record via Reference fields and not just the field itself.  So...

user.location.country.getValue();

...is an example of getting the Country information from the "location" record tied to the "user" record via the Reference field using the dot-walking method.  The "country" part is on the "location" record and not the "user" record.  Here you are dot-walking (accessing) to the location record and then accessing the Country field on a completely different record.

Getting or setting the value of the user.location field is not an example of dot-walking.  "location" is just a property on the "user" record object.  You reference the field or property using the "record_name.field_name" format.

[jonsan09 · Accepted solution]

Tim Woodruff has a great article on the subject: https://snprotips.com/blog/2017/4/9/always-use-getters-and-setters