Hi,

I am trying to complete a challenge where I need to install an app from AppExchange. To do this, I need to know my password. Unfortunately I am unable to change my password in my Playground. I have tried to follow the trails: "Get Your Trailhead Playground Username and Password" and the help article how to change password in the "setup --> users". However when I try to access the "users" page, the connection fails and it kick me out of the playground environment. If I then click "Forgot Password" and follow the instructions in the email, I get a security question which I dont have the answer for. Not sure if this is caused by permissions. I have tried to create a new playground environment, however still get the same issue.

Hopefully somebody can help with this.

Cheers,
Casper

I can schedule a job via Apex code:

 

System.schedule('test', '0 0 0 * * ?', new SchedulableClass());

 

The CronTrigger job doesn't have a "Name" field, so I can't query for the Job I just created.  This means I can't check to see if my job already exists calling System.schedule(); instead I just have to call "schedule()" and silently eat the exception it throws if the job already exists.

 

The only way you can figure out which CronTrigger is yours is to cache the return value of System.schedule(), which (it so happens) is the ID of the CronTrigger that is created.  However, you can't delete them from Apex:

 

 

Id jobid = System.schedule('test', '0 0 0 * * ?', new SchedulableClass());
delete new CronTrigger(Id = jobid);

// 'delete' throws 'DML not allowed on CronTrigger'

 

 

So the current state of Scheduled Jobs is:

 

You can create them from Apex Code, but not from the UI

You can delete them from the UI, but not from Apex Code

 

I guess that just seems odd to me.  Why did Salesforce create this whole new API (System.schedule()), with a seemingly random assortment of ways to manipulate it, instead of just exposing the CronTrigger table directly to the full range of DML operations?

 

Placing new functionality into new core objects, rather than new APIs, seems easier on everyone (the whole describe/global describe suite of API calls are an example of something that seems a natural fit for a set of read-only custom objects).

Hello,

Here is a phrase (highlighed in red below) I do not understand in this Trailhead: Buld Apex Triggers.


I totally do understand the benefits of bulkifying SOQLs and DMLs in apex triggers and/or apex Classes.

But, I think this phrase (forgive my poor English) is refeering to statements where you combine a for each loop and an SOQL ? Like below, in lines 5 and 6:

trigger SoqlTriggerBulk on Account(after update) {  
    // Perform SOQL query once.    
    // Get the related opportunities for the accounts in this trigger,
    // and iterate over those records.
    for(Opportunity opp : [SELECT Id,Name,CloseDate FROM Opportunity
        WHERE AccountId IN :Trigger.New]) {
  
        // Do some other processing
    }
}

But, I do not quite understand the relationship between the fact that you can "unify" in one statement the for each and the SQL AND a potential "Benefit" to do this in terms of performance or efficiency.

What do you mean by "benefit of SOQL for loop"?

Thank you  very much.