Wednesday, 29 August 2018

Soql Queries and Sub Queries


In the below query there are total 3 subqueries + 1 parent query. So, there are 4 queries. But, Salesforce doesn't count subqueries against governor limit of 100 SOQLs. It counts only root query which means only 1 SOQL query would be consumed.


List<Account> dd = [
    SELECT
        id,
        (SELECT Name FROM Contacts),  // <- first subquery
        (SELECT AccountID FROM Cases) // <- second subquery
    FROM
        Account
    WHERE
        id
    IN (SELECT AccountID FROM Case)   // <- not counted
];


Subqueries are counted separately as AggregateQueries. You can check those with Limits.getAggregateQueries() and Limits.getLimitAggregateQueries(). You cannot have more than 300 aggregations in a single transaction.

For example: Org contain  only 2 Account and each have 10 Contacts.

 If you execute this with sub Query like below

Select Id, Name, (Select Id, Name from Contacts) From Account

Then the total number of Query rows will be 22 (2+10+10).

 From above analogy we can understand like this:

 If your org contain 40M accounts and each have 1 contact.

Then in this scenario you can use sub query up to 25M only.

 Like this Select Id, Name, (Select Id, Name from Contacts) From Account limit 25M

Monday, 20 August 2018

will System.debug, if left in production, affect performance ?


Code executed, including System.Debug and System.assert (and their variants) have the following effects:

1) They increase debug log sizes.
2) They increase script execution time (but insignificantly).
3) They count against governor limits.

The final bullet point is your most troubling concern. A loop against 1000 records with 10 debug statements will have a total of 10,000 extra script statements than the one without.

The salesforce.com best practices state that you should always remove or comment debug statements for production code

Monday, 13 August 2018

Test.setup:



  • @testSetup ( Set Up Test Data for an Entire Test Class )Use test setup methods (methods that are annotated with @testSetup) to create test records once and then access them in every test method in the test class.
  • Test setup methods can reduce test execution times especially when you’re working with many records
  • Test setup methods enable you to create common test data easily and efficiently.
  • Test setup methods enable you to create common test data easily and efficiently.

@isTest
private class CommonTestSetup
{
 @testSetup
 static void setup()
 {
  Account acct = new Account();
       acct.Name = 'Salesforce.com';
       acct.Industry = 'Technology';
  insert acct;

  Contact cont = new Contact();
       cont.FirstName = 'Annappa';
       cont.LastName = 'ph';
       cont.AccountId = acct.Id;
  insert cont;
 }
 
 @isTest
 static void testMethod1()
 {
  Account acct = [SELECT Id FROM Account WHERE Name='Salesforce.com' LIMIT 1];
     acct.Phone = '555-1212';
  update acct;
 }

 @isTest
 static void testMethod2()
 {
  Account acct = [SELECT Phone FROM Account WHERE Name='Salesforce.com' LIMIT 1];
  System.assertEquals(null, acct.Phone);
 }
}

Note:

If a test class contains a test setup method, the test setup method executes first, before any test method in the class.
Multiple @testSetup methods are allowed in a test class, but the order in which they’re executed by the testing framework isn’t guaranteed
If the test class or a test method has access to organization data by using the @isTest(SeeAllData=true) annotation, test setup methods aren’t supported in this class.
 Date Formats and Date Literals
                                                 

DateTime field values are stored as Coordinated Universal Time (UTC).

When a dateTime value is returned in Salesforce, it’s adjusted for the time zone specified in your org preferences.

If you want to process these values in different time zones, your application might need to handle the conversion.

For a fieldExpression that uses date formats, the date is not enclosed in single quotes. Don’t use quotes around the date.

For example:

SELECT Id
FROM Account
WHERE CreatedDate > 2016-10-08T01:02:03Z

Date Literals:

Simple Queries:



 SELECT Id FROM Account WHERE CreatedDate = YESTERDAY

SELECT Id FROM Account WHERE CreatedDate > TODAY

SELECT Id FROM Opportunity WHERE CloseDate = TOMORROW

SELECT Id FROM Account WHERE CreatedDate > LAST_WEEK

SELECT Id FROM Account WHERE CreatedDate < THIS_WEEK

SELECT Id FROM Account WHERE CreatedDate < THIS_MONTH

SELECT Id FROM Account WHERE CreatedDate = LAST_90_DAYS

Saturday, 11 August 2018

Salesforce Basics :



Using same List for Update:

List<Account> acList=[select id,name from account limit 2];
system.debug('>>>acList>>>>'+acList);
for(account ac:acList){
    ac.name='Test';
}
system.debug('before update List>>'+acList);
update acList;

Here "acList" contains Updated value



Will It Updates.Parents name field?

List<Contact> contactList=[select id,accountId,account.name from contact limit 2];
for(contact c:contactList){
c.account.name='Update Parent Account';
}

update contactList;

Ans: It will not