Some bugs are hard.
Last week I had one of the hardest. It only happened occasionally, after a row lock error, in very specific scenarios, on a customer production org. It was, of course, impossible to reproduce. And given that it only occurred now and then for random users, capturing a debug log was out of the question.
So what do you do? You go old-school. Search the code for any execution path that could possibly lead to the results we saw in the data. And after many hours of research, I found nothing. There was no scenario that could lead to the results we were seeing. And there were no workflows, processes or flows that could do it either. We started wondering if maybe some outside integration was involved, but that seemed unlikely.
Well, there’s that old saying “When you’ve eliminated the impossible, whatever remains, however improbable, must be the truth”. There was one “impossible” code path that could theoretically lead to what I was seeing, but it could only happen in one case – if you could somehow read a field from an SObject that was not included in a query, having it return null instead of throwing an exception.
You’ve all seen this exception. Imagine a custom object Soql_Query_Test__c that has two fields, Test_Field_1__c and Test_Field_2__c and you execute the following code
Soql_Query_Test__c sqt =
[Select ID, Test_Field_1__c
from Soql_Query_Test__c Limit 1];
String s = sqt.Test_Field_2__c;
The result is the notorious SObjectException “SObject row was retrieved via SOQL without querying the requested field: Soql_Query_Test__c.Test_field_2__c”
I’ve seen that exception many times. It’s invaluable during development and testing when it comes to making sure that all of the fields we use are in a query. But the only way our bug was possible was if I could read an unqueried field without raising that exception.
I tried everything I could think of – converting the object into a generic SObject, passing it to functions and accessing the field there. The exception always appeared. Was I on the wrong track? Was this actually happening? What could our code be doing?
Fortunately, we have unit tests – good unit tests. We even have unit tests that simulate row locking exceptions, so I was able to run that code path, though not for the exact scenario that would reproduce the bug. Still, I could set some fields in a source record, add some debug statements and see exactly what happened.
And sure enough, the improbable was true. I had a record. It had a field that had a value in the database but was not included in the query. I confirmed it was not included in the query using the wonderful SOBject.GetPopulatedFieldsAsMap function. But when my code accessed the field, the value was null. No exception. Null. I was floored.
I started trying other things in the org where I was experimenting – different field types, dynamic vs. static DML, dynamic vs. static queries, and finally had a breakthrough. I set the other field to a random value, and the exception vanished.
Soql_Query_Test__c sqt =
[Select ID, Test_Field_1__c
from Soql_Query_Test__c Limit 1];
sqt.Test_Field_1__c = 'Changed value';
String s = sqt.Test_Field_2__c;
This results in no exception, and the string is set to null.
If you set any field in a record, reading any unqueried field on the record will return null instead of raising an exception.
I had my answer, and was able to implement a solution so we could patch the bug. But I’ll be honest, at this point my biggest question was – how could I not have known about this?
Is it a Bug, or a Feature?
The next day I reached out to Don Robins who is an expert trainer. He knew about this, and his view, and that of another trainer he spoke to was that this was a known and expected behavior. The reasoning: that once you set any field in a retrieved record, further missing field SObjectExceptions are disabled under the assumption that you (the developer) know what you are doing at this point.
Robert Watson, a co-worker and expert Apex developer hadn’t seen this, but found the following StackExchange post: https://salesforce.stackexchange.com/questions/160112/sobjectexception-no-more-intentional-change/163429#163429
This post suggests that it was a bug that was introduced late 2017. But I knew our code dated to mid 2016. Fortunately, it’s possible to set the API version for an Apex class, so I set the class I was experimenting with to API 24 – which is about 6 years ago – and saw the same behavior. This leads me to conclude that either this behavior has always existed, possibly by design, or that it was an unversioned change.
You may wonder how could an unversioned change this significant occur and not be detected? What about the infamous Hammer test?
Well, think about what would have actually happened when this change was introduced. Existing code would continue to work. The lack of an exception would only break a test that was checking to verify that a missing field exception occurs – and what would be the point of such a test? In truth – this is not going to be a breaking change, and while it might have been caught by an internal Salesforce validation test, it’s highly unlikely any customer orgs, functionality or unit tests would be impacted.
A friend of mine at Salesforce brought the following known issue to my attention: https://success.salesforce.com/issues_view?id=a1p30000000jfXtAAI suggesting that it is a bug. And yes, I did miss this when searching for existing issues before doing my own research. Oops – lesson learned (again).
So this brings us to the big question: is this a feature? Is it an unversioned change? Or is it a bug? And ultimately, should this behavior be changed?
It’s not an easy question to answer.
Does it make sense to ignore unqueried fields once you’ve set any field value? I can see the logic in that argument, but let’s rephrase it.
When updating a record, do you ever read fields on that record? Of course you do. And is there any scenario where, on reading an existing field, you would intentionally leave it out of the query string in order to return null instead of the existing value? Probably not.
Yes, you can make the argument that the developers should know what they’re doing and make sure to query all fields, but we developers make mistakes. And the earlier we find a mistake, the better. Which scenario is more likely to help discover a missing query term earlier – an exception, or returning null? Obviously, the exception. The only way you’d detect the incorrect null field value is if you looked for it, or saw the consequences later in the data – as I did. So while it makes sense to me to allow writing fields that were not queried, I think it would be better for developers to have the exception always occur when accessing unqueried fields that have not been explicitly set.
So I’m leaning towards the “it’s a bug” camp… but is this a bug worth fixing?
The nature of this “bug” is the lack of an exception. How much code exists out there where someone queries a record, writes a field, and then inadvertently reads an unqueried field? Especially considering that this behavior may have existed from the earliest days of Apex? I’m afraid to even ask – the number could be enormous.
Sure, they would version this fix. But then you’ll have a new version of Apex where an exception might be thrown that wasn’t thrown before. Everyone will have to test their code. Unit tests will help, but only for those who have good unit tests, and even then, there can easily exist code paths where the bug was missed – which could lead to the sudden appearance of intermittent and occasional exceptions in code that is currently working for anyone who wants to upgrade their code to a new API version. For some orgs this could present a costly and risky obstacle to upgrading to a new API version – at exactly the time where the new Apex compiler promises to bring new enhancements to the language.
So yes, it may be a bug, but this may be a bug where the cure costs more than it’s worth. In which case, there’s only one thing left to do – turn it into a feature and document it.
Whichever approach they choose, this has been a fascinating case – I hope you found it as interesting as I did. And please spread the word – this behavior is something every Apex developer should know about and consider both at design time and when creating unit tests and QA plans.
I know what you’re thinking – what? Blockchain on Salesforce? Are you kidding?
I’m not kidding.
This course came about from a simple question: Is there actually a useful scenario for blockchain on the Salesforce platform, and if so, would it be possible to implement in Apex?
It turned out, rather to my surprise, that the answer to both questions is yes. The result is this course.
The course starts with a very basic introduction to blockchain technology. Yes, it does cover crypto-currencies and explains why you definitely would not build one of those in Apex (sorry, this course won’t make you rich mining some hypothetical Force-coin).
You’ll then learn some actually useful applications for a private blockchain on Salesforce, and then see a full implementation of a blockchain in Apex
Grab yourself a free trial on Pluralsight and check it out for yourself!
Building a Private Enterprise Blockchain on Salesforce – on Pluralsight.com
Every admin and developer in the Salesforce world uses formulas – they are everywhere. And everyone learns them – sort-of. People tend to pick things up along the way, tweaking an existing formula here, reading the online docs there, borrowing from an online source – everywhere.
As a result, even experienced admins and developers tend to have holes in their knowledge – a less than complete understanding of data types, or of formula limits – or, and don’t get me started – endless confusion when it comes to logical operators (And, or, Not – you now – the ones that cause most formula bugs).
In my latest course, Formula Fundamentals in Salesforce, you’ll go back to the basics with in-depth coverage of Salesforce formulas. You’ll learn about data types, operators and functions – limits and testing. And yes, those dreaded logical operators and how to translate human logic into formula logic, and then validate that you did it correctly and test your work.
Watch Formula Fundamentals in Salesforce on Pluralsight
One of the more interesting challenges in Salesforce has to do with updating related records. For example: If you change the owner of an account, you might want to change the owner of all contacts for the account, and then maybe change the related tasks for those contacts and so on.
While there is some support some some situations (such as changing a single account owner using the UI), the general problem of doing so in bulk is actually quite challenging, as the number of related records that need to be updated can be huge.
If you’re interested in digging deeper into this subject, check out my new course on Pluralsight – “Play by Play: Managing Data in Salesforce using Apex“.
Play by play courses are a bit different than most. Instead of watching me present a screen cast, you’ll watch a video where I sit down with Don Robins and build out a solution in real-time. You get to see the entire development process, including the creation and resolution of bugs along the way. You’ll watch as I implement several different approaches, including some common ones that have hidden flaws that might not appear until long after they are “successfully” deployed.
As always, you can easily sign up for a free Pluralsight trail to watch the course if you aren’t currently a subscriber.
Watch Updating Related Records in Apex on Pluralsight
Like many developers, I believe the future of Force.com development is Lightning, with Lightning components giving programmers the ability to create rich user experiences in ways that have not been possible before.
I invite everyone to check it out – you can get a free trial on Pluralsight if you aren’t already a subscriber – you’ll find a growing library of other Salesforce courses there as well.
This week at the MVP summit I introduced SearchTheForce.com – a new search engine for all things Salesforce.
Like most developers (and I expect Admins and users), I rely heavily on Google to find answers to questions. And by heavily I mean – heavily. The fact that I can easily search for things means I don’t have to worry about remembering them, and can concentrate instead on the problem at hand. SearchTheForce.com makes my search more efficient, in that I don’t have to be clever with my search terms to try to convince Google that I’m interested in a workflow formula instead of feeding a baby. It is my hope that others find it just as useful.
SearchTheForce.com is still Google – it uses a technology called Google Custom Search. The site also supports a feature called OpenSearch – which means that browsers recognize it as a search engine. On Chrome once you’ve visited the site you can enter a few characters like “sear” then press tab to specify a SearchTheForce.com search, and enter your query directly into the search/URL bar. On Firefox, you can add it as a search engine that is available to the search box. You can even make it your default search engine.
Right now SearchTheForce.com searches all Salesforce domains, popular Salesforce forums such as the StackExchange, and a large number of Salesforce related blogs. If there’s a site that’s missing, there’s a suggestion page where you can send in your site recommendations.
The Back Story
Many years ago, when Google first introduced custom search, I created a search engine for Microsoft .NET technologies called SearchDotNet.com. It was a great learning experience and a useful tool. A couple of months ago I received an Email from someone using that site who had a suggestion. My response was “wait, that site is still up?” I had completely forgotten about it. But it reminded me about this technology and I instantly realized that I desperately needed a custom search for Salesforce. In fact, I rather kicked myself for not having thought of this years ago.
I was also looking for a good excuse to get acquainted and reacquainted with Linux technologies – I hadn’t done any real work in Unix since the 1980’s, and wanted to refresh and update my knowledge of that technology stack. Building out SearchTheForce.com was a great excuse to do that.
The site is built on an Ubuntu server running WordPress on Nginx – based on my research that was the best way to build a high performing WordPress server. It’s running on AWS – another technology stack that I’m familiar with, but by no means an expert. Overall, it was a great learning experience, and it seems to run very efficiently on small EC2 instance.
Integrating Google Custom Search was not difficult – there are several plugins available for this on WordPress, though I confess I ended up heavily modifying the one that I used to migrate it to the current version API and to support OpenSearch. Using WordPress made it easy to implement other features like adaptable layout and the suggestion page, and will make future updates easy if necessary.
Configuring the Google Custom Search itself is easy. In fact, I discovered after the fact that there was another Salesforce custom search out there, but that’s ok – the more the merrier. In fact, if you have a site and you’d like to add SearchTheForce.com’s search to your own blog or site, drop me a line and I’ll be glad to show you how to do it.
Meanwhile, I hope you enjoy it, and next time you have a question and turn to Google for an answer, you’ll search the Force.com instead.
Update – The real TrailheadX agenda is now posted https://developer.salesforce.com/trailheadx/agenda. If you’re attending be sure to stop by the Campfire Tales session being put on by Pluraslight on Wednesday at 12:40!
Like everyone else, I await the official agenda for TrailheadX – the first Salesforce developer conference.
However, being as impatient as I am, I did some digging (through my imagination) and came up with a short list of some of the amazing experiences we can look forward to. Here they are:
- Everyone will get loaded onto RVs for learning on the road with Jeff Douglas @jeffdonthemic – learning coding while driving through California’s beautiful state and national parks.
- You’ll then practice your skills on tablets as naturalists guide you on a nature trail as part of the innovative Trailhead on Trailheads program.
- TrailheadX takes place on the same day as the California primary. Donald Trump will lead a hands on training of implementing wall management on Salesforce platform using advanced currency management (since it’s going to be paid for in pesos) assuming he can get currency management to work (See here ).
- A Benjamin Franklin lookalike will demonstrate building a mobile electrical system management app built on Lightning.
- As part of our commitment to community service we’ll be reaching out to the homeless – the thousands of San Francisco tech workers who struggle to afford a bed in a hacker dorm while only making six figures.
- Featured performance by Adele singing her hit song “Hello World”
I can’t believe I forgot to post a blog entry about my latest Pluralsight course “Career Strategies and Opportunities for Salesforce Platform Developers“.
Ok, it was released right before Dreamforce, and the last two months have been considerably crazier than normal. But still…
Anyway, I encourage you to check it out. Those of you just starting out on the platform will find some great resources and information for helping you move your career forward (and understand better what you’ve gotten yourself into). Those of you who are experienced on the platform will finally have something to point your friends to that explains what’s really going on, and why they should seriously consider working on the platform as well.
Ideal for developers and administrators (and developers who wish to become administrators and vice versa), and all those who are curious about career opportunities on the Salesforce platform.
The third edition of Advanced Apex Programming is now available!
And have I got a deal for you!
I’ve often been asked by people, what’s new in this edition and is there any way to get a discount on upgrading? Now there is a lot new in this edition – with numerous changes throughout the book both in content and in recommended best practices. The chapter on asynchronous programming has been almost completely rewritten to address queueable Apex (yes, all of the previous best practices have been rendered obsolete), and there’s a new chapter on maintaining Apex.
But how do you offer upgrades on a book? It’s not like software, where people can register and updates can detect previous versions. Or SAAS applications where the upgrades come with your annual subscription.
Also, in previous years, Salesforce licensed a special printing for distribution at Dreamforce, which was great for Dreamforce attendees, but not so good for everyone else. This year timing and their budget didn’t allow for that.
Still, it’s the Dreamforce time of year, right? Good time to do something special.
So, I decided to do an experiment – and offer “upgrade” pricing to everyone.
For the next 90 days the eBook version will be available on Amazon Kindle through their Select program – at a price of 9.99 (or whatever the Kindle select pricing is where you are). Prime customers will be able to borrow it. Kindle unlimited customers can just download it. After 90 days, it will revert to the normal $34.99 or equivalent price (unless the experiment is so successful that it makes more sense to extend the deal).
Books are a lot more limiting – I don’t have the same flexibility I have with the EBook. But there is one channel where I do have the ability to offer a great discount. So for those of you who want a new printed copy, I can do this – if you go to the book’s store on createspace, you can get a 50% discount by entering this code on checkout CDUK54Z5 – 50% off the regular price of $39.95. Keep in mind, this code ONLY works on that store, and yes, they can ship internationally. This offer, which is sponsored in part by Full Circle Insights (which you should check out for our great marketing analytic tools), is good for 30 days, after which it too can go away at any time.
So that’s the deal. No free books at Dreamforce, but upgrade pricing for everyone for a limited time. Hopefully this approach will be more fair, and still provide a reasonable return (because I have to tell you – it was a lot of work!)
Purchase the print version with upgrade pricing – Use code CDUK54Z5 on checkout for the discount.
Purchase the Kindle version with upgrade pricing:
(note, it may take a few days for the printed edition of the book to appear on some international Amazon sites – I’ll update the home page as I see them become available)
Stack Overflow just posted their annual developer survey for 2015 – http://stackoverflow.com/research/developer-survey-2015. I was more than a bit surprised that Salesforce development topped the list of most dreaded technologies. Now I’m not questioning their results, but you know what Mark Twain is misquoted as having said – there are lies, damned lies, and statistics, and this one didn’t quite pass the smell test for me. I know a lot of Salesforce developers at all levels, and if 73% of them dreaded working on the platform I would expect to be having quite a few conversations consisting of people complaining about the platform and how they are studying other technologies in the hope to escape those dreaded limit errors.
In the survey, dreaded is defined as “% of devs who are developing with the language or tech but have not expressed interest in continuing to do so.” I know many developers who have come to Apex from other languages. I can’t think of any of them who are looking to do something else. There are some great things about developing on the Salesforce platform, and some very annoying things as well. I can see how someone coming to Apex from another language might find aspects of it very frustrating (don’t we all?) but I think most of us find the advantages far outweigh the disadvantages. Enough so that we are generally very interested in continuing to work on the platform as it evolves.
Something isn’t quite right.
So I asked myself, who were the respondents to the survey? It must have been a fairly small sample of Salesforce developers, after all Salesforce doesn’t even appear on the list of popular technologies (defined as most used), so less than 7.8% of the respondents would be Salesforce devs. Of course, this could still be a statistically significant number, but it does suggest that Stack Overflow does not necessarily attract large numbers of Salesforce developers.
And why would it? Any experienced Salesforce developer is much more likely to be active on the similarly named and often confused Stack Exchange – specifically Salesforce.StackExchange.com. If you look for answers on Salesforce or Apex questions, you’re much more likely to be directed there than Stack Overflow. Looking at Stack Overflow, the tag Apex has 667 questions. Apex on Stack Exchange has 7000 questions. Does this mean that Salesforce developers who are happier on the platform are more likely to be on Stack Exchange than Stack Overflow? Are the Salesforce devs on Stack Overflow more likely to be part time on Salesforce where those on Stack Exchange are full time on the platform? Are developers who spent their time on Stack Exchange less likely to have seen the ads for the survey (which are noted as appearing on Stack Overflow sites)? I have no idea. But I’d bet there’s a selection bias at play here, and I’d bet it’s significant.
So I call bullshit on this statistic. I think it falls into the category Stack Overflow uses to describe the results where “These results are not unbiased. Like the results of any survey, they are skewed by selection bias, language bias, and probably a few other biases.”
I think there is some extreme selection bias going on here. Nothing against Stack Overflow by the way – they are very transparent about the results and potential for bias. Unfortunately, I’m afraid a lot of people will look at that number and assume it means something, where in fact the hitherto unasked question – of how many Salesforce developers actually dread the technology they are working on, remains unanswered.