Salesforce: Some Insights

What? Simulated breakpoints a.k.a. checkpoints enable developers to assign breakpoints to assess stack values at that point of execution. Where? Simulated breakpoints are available in new Developer console.  Why? At many occasions developers need to assess variable/ instance values during execution. This comes in very handy especially when debugging something in production wherein developers cannot add "system.debug" statements at their will. With breakpoints, developers can very well place breakpoints at desired code locations and execute the code to get breakpoint results How? To create checkpoints, open a class/ trigger in developer console and click on left hand side (just next to line no.). Once added, you can view your breakpoints in "Checkpoint Locations" sub tab within Checkpoints tab.  Each execution of class/ trigger generates Checkpoint data in "Checkpoints" sub tab. Double click on the individual checkpoint log, to view correspondin...

What? Polymorphic key is a relationship field which can relate to more than one type of object as parent. Unlike Lookup and Master-detail relationships which are related to a single object, Polymorphic keys can refer to multiple objects. Where? As of date, Polymorphic keys cannot be created by developers. They are available for specific objects out of the box for e.g. WHOID and WHATID in Task and Event objects. Why? As we know, Salesforce’s data model is strictly relationship based, and the type of objects at both the ends of the relationship is fixed. So, if an object is to be related with multiple objects, then a separate relationship field has to be created for each relationship. Polymorphic keys are required to maintain relationship with multiple types, for e.g. task/ event might be related with various type of records viz. Account, Contact etc. So, a polymorphic key helps in establishing unique access to such disparate relationships. How? Polymorphic keys ...

How many of you have faced problems understanding the basic difference between Object relationships (as provided by Salesforce.com) and Table/entity Relationships (as provided in conventional RDBMS)? I am sure many of you must have faced the same problem, at least I did. But lately there are some new enhancements in SOQL which narrows down these differences. For e.g now in SOQL you can have INNER JOINS and you can group data using the famous GROUP BY clause. So, what is the big deal? Well, yeah it’s not a big deal that you can - do more in SOQL and remove your earlier code using which you used to retrieve data in case of INNER JOINS or - group your data using GROUP BY clause and have conditions on it using HAVING clause or - use some new Date functions in your SOQL query to filter your data (which you used to do using Apex code). So, in all it means richer SOQL and lesser use of Apex for these purposes. Interested, then checkout a very good article written by Dr. Umit Ya...