• DaveFF
  • NEWBIE
  • 10 Points
  • Member since 2016
  • Developer
  • Future First


  • Chatter
    Feed
  • 0
    Best Answers
  • 0
    Likes Received
  • 0
    Likes Given
  • 2
    Questions
  • 1
    Replies
I am writing (and testing) a Batch Apex job that starts off by looking up Contacts who have a particular type of Task. Each such Task should only contain one Who (a Contact) and one What (an Account), but I want the code to be future-proof. I am at this stage only interested in the IDs of the Contacts, so I tried querying the TaskWhoRelation, and was surprised to find it empty. Adding extra assertions to the test reveals inconsistent behaviour between TaskRelation and TaskWhoRelation.
    System.assertEquals(1, [
      SELECT COUNT()
        FROM Task
       WHERE Activity_Type__c = :SurveyOrgBatch.ACTYPE_WAYN
    ]);
    System.assertEquals(1, [
      SELECT COUNT()
        FROM TaskRelation
       WHERE Task.Activity_Type__c = :SurveyOrgBatch.ACTYPE_WAYN
         AND IsWhat = false
    ]);
    System.assertEquals(1, [
      SELECT COUNT()
        FROM TaskWhoRelation
       WHERE Task.Activity_Type__c = :SurveyOrgBatch.ACTYPE_WAYN
    ]);

I insert a single Task with the WhoId and WhatId set to appropriate test records. The first two assertions pass. The third fails with "System.AssertException: Assertion Failed: Expected: 1, Actual: 0"

I guess I can just use TaskRelation instead, but can TaskWhoRelation be used in batch jobs? During testing? In things that are tested?
  • March 22, 2017
  • Like
  • 0
I have the following code in a trigger on Account (after update). It's a bit of a hack because I want certain formula fields on certain Contacts to sync to Mailchimp, so their last modified date needs to be touched. I'm now (a week or two later) unable to Update a new field on Opportunities using the Data Loader, as an error down the chain of triggers says "System.QueryException: Non-selective query against large object type (more than 200000 rows)" for this.
List<Contact> teachers = [
    SELECT Id
      FROM Contact
     WHERE AccountId IN :schoolIds
       AND RecordType.DeveloperName LIKE 'Client%'
       AND Account.RecordType.DeveloperName = 'School_or_College'
  ];
The query should only ever return less than 100 rows. The table contains ~215k rows. I guard against emptiness or presence of nulls in schoolIds, which should be a very small set (most likely only 1). Consulting this cheat sheet and Setup/Customize/Contacts/Fields, I note that lookups and record types are indexed. I don't see any of the automatic exceptions to index selectivity- I'm tempted to suspect the LIKE clause but the wildcard is at the end.

Why is this query non-selective, and what can I do to make it better? (Using record type IDs rather than DeveloperNames? Splitting out the last WHERE clause into a separate preliminary query?)
  • February 22, 2017
  • Like
  • 0
I have the following code in a trigger on Account (after update). It's a bit of a hack because I want certain formula fields on certain Contacts to sync to Mailchimp, so their last modified date needs to be touched. I'm now (a week or two later) unable to Update a new field on Opportunities using the Data Loader, as an error down the chain of triggers says "System.QueryException: Non-selective query against large object type (more than 200000 rows)" for this.
List<Contact> teachers = [
    SELECT Id
      FROM Contact
     WHERE AccountId IN :schoolIds
       AND RecordType.DeveloperName LIKE 'Client%'
       AND Account.RecordType.DeveloperName = 'School_or_College'
  ];
The query should only ever return less than 100 rows. The table contains ~215k rows. I guard against emptiness or presence of nulls in schoolIds, which should be a very small set (most likely only 1). Consulting this cheat sheet and Setup/Customize/Contacts/Fields, I note that lookups and record types are indexed. I don't see any of the automatic exceptions to index selectivity- I'm tempted to suspect the LIKE clause but the wildcard is at the end.

Why is this query non-selective, and what can I do to make it better? (Using record type IDs rather than DeveloperNames? Splitting out the last WHERE clause into a separate preliminary query?)
  • February 22, 2017
  • Like
  • 0