Retrieve, Modify, Persist – Part 6

Modify

In the past 5 chapters of this journey, we’ve learned many ways to fetch records efficiently from the database. It’s now time to focus on how can we alter those retrieved records to capture new information or update existing ones. This post will guide you through some considerations and best practices to modify information in memory during an Apex transaction.

I’ve got a data set…now what?

Once you have successfully fetched a set of records, you will to iterate efficiently through the retrieved records. In a previous blog post we provide the Apex Loop Cycles guide that can help you select which one is best for your needs.

But Wait! We need to talk about Security

By default, Apex runs in System Mode. This means that, regardless of which user is accessing our code, the system will ignore the Record access setting and the Field Level Security and execute the code as if a System Administrator (a user with FULL read/write access) is running the processes. You can see how this could be a problem.

The first concern is whether the user in context has:
1. Access to the record she/he wants to modify.
2. Access to the field the field that needs to change.

Controlling Access to Records in Apex

As long as you have defined your Organization-Wide Defaults or OWD, (see my earlier blog series), it’s easy to enforce your sharing settings in your Apex Code. Just use the with sharing keyword in your apex class declaration.

The with sharing keyword tells Apex to apply the sharing rules settings of your Org, and the result are SOQL and SOSL queries automatically filtered for the context of the invoking user that will return only the records he/she has access to. The following picture shows how to properly specify the keyword:

 Classes that implement with sharing  benefit from it by having less complex queries and better performance, since they usually handle a much smaller data set. 

It’s important to consider that this keyword applies in the context of the class that is executing the code. Let’s say you have a VisualForce Page controller declared without the with sharing keyword. Any query you execute within your controller will execute in system context; however, if you call a method from another class that enforces the with sharing keyword, queries executed as part of that class will return data sets filtered to comply with sharing rules settings.

Verifying Access to an Object’s field in Apex

f you want to confirm your invoking user has permission to access to the fields they’re querying, it takes a bit more code. You’ll need to use the sObject describe methods within your code before performing the needed update.

The following code snippet shows how to verify if a field is updatable: 

One best practice is to have these highly-reusable methods in a separate Utils class and call them when necessary, like this:

In the past, the sObject describe method calls were bound by governor limits, but as of Summer’14 there are no more limits attached to these types of calls. So don’t be shy using them in your code and as part of your Developer toolbelt!

In our final post for this series, we will talk about the Data Manipulation Language, or DML for short. We will explore the different ways we can save changes into the Salesforce database and how each of them benefit you as a developer.

 

About the Author:

Clara Perez is a Salesforce MVP and Lead Developer at Great Wave who loves teaching Salesforce concepts.