6

I'm not sure what to make of this one and am hoping someone can see what I'm missing.

Create the following Global class on a summer 13 org:

global class IDCompareTest implements Schedulable {

  global void execute(SchedulableContext sc)
  {
    ID triggerid = sc.getTriggerID();

    List<CronTrigger> cts = [Select ID from CronTrigger where ID = :triggerid];
    system.debug(triggerid);
    system.debug(cts[0].id);
    // These two IDs should be the same (15 character trigger ID and 18 character queried ID)
    System.Assert(triggerid == cts[0].id);
  }
}

And the following test class:

@istest
public class TestIDCompareTest{

  public static testmethod void test1()
  {
      Test.StartTest();
      String res = System.schedule('test job ' + String.ValueOf(DateTime.Now().getTime()), GetCRONExpression(DateTime.Now().addseconds(5)), new IDCompareTest());
      system.debug('scheduled job ' + res);
      Test.StopTest();
  }

  public static String GetCRONExpression(Datetime dt) {
    return ('' + dt.second() + ' ' + dt.minute() + ' ' + dt.hour() + ' ' + dt.day() + ' ' + dt.month() + ' ? ' + dt.year());
  }
}

The triggerid ID variable is set to the 15 character ID returned from getTriggerID() The cts[0].id is the 18 character ID for the same job. The two values will match in the first 15 characters. So - the ID comparison should succeed.

However, I'm getting a failure on the assert.

I did not see this problem on Winter 13.

I would appreciate it if anyone can let me know if they can reproduce it, and if I'm missing something obvious.

Thanks

7
  • I've seen a few people comment in various forums about Summer 13 and IDs. This and This – Daniel Hoechst Jun 7 '13 at 22:59
  • Thanks Daniel. I looked at those threads and I don't think it's the same issue, though it may be related. For one thing, those seem to deal with final static variables, which isn't the case here. – kibitzer Jun 7 '13 at 23:07
  • Yes, I agree yours is different, but quite suspicious that there are several different issues around IDs with this release. – Daniel Hoechst Jun 7 '13 at 23:44
  • FYI, I just pushed this Known Issue System.assertEquals() fails for identical Map<ID,ID> in summer 13 thru that was a Summer '13 regression involving Id comparisions. CC @DanielHoechst – mjgallag Jul 19 '13 at 16:51
  • Interesting - not exactly the same issue (which has been fixed), but certainly a problem. – kibitzer Jul 20 '13 at 18:29
1

I am taking a chance here using System.Assert(triggerid == cts[0].id);comapares for the exact match but when you use FAIL:

   System.Assert(string.valueof(triggerid).equals(string.valueof((cts[0].id)))); your test case will pass. 

Give it a try !!!

update: The below assertion passed : (Still no idea why System.Assert(triggerid == cts[0].id); the assertion wont pass in summer 13 box)    

FAIL:

 System.Assert(string.valueof(triggerid)==(string.valueof((cts[0].id)).substring(0,15)

PASS:

System.Assert(string.valueof(triggerid).equals(string.valueof((cts[0].id)).substring(0,15)
        ));
4
  • 1
    Did you try this? I'm seeing a failure on that assert. In fact, I'd expect a failure on that assert, because the 15 and 18 character ID when converted into a string should not match. However, the 18 and 15 character IDs when compared as IDs should match - but they aren't, which is the puzzle. – kibitzer Jun 7 '13 at 22:08
  • I am trying this, will update you soon – Rao Jun 7 '13 at 22:09
  • This is likely related to the bug I posted on the forums (the one that nobody ever responded to). See BUG: Id.valueOf does not identify Id values correctly. – sfdcfox Aug 8 '13 at 13:59
  • String a = '00130000006T5of', b = '00130000006T5ofAAI'; Id c = '00130000006T5ofAAI'; System.debug(LoggingLevel.ERROR, a == b); system.debug(logginglevel.error, id.valueof(a) == id.valueof(b)); system.debug(logginglevel.error, ((id)a) == ((id)b)); system.debug(logginglevel.error, b == c); results in false, false, false, true. – sfdcfox Aug 8 '13 at 14:04
0

Just found that == operator when used on ID's performs a case sensitive comparison. I believe that is why the 18 and 15 character IDs when compared as IDs is failing.

Note that the == operator also performs String comparison, but is case-insensitive to match Apex semantics. (== is case-sensitive for ID comparison for the same reason.)

source : http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_methods_system_string.htm

Hope this answers your question

1
  • 1
    It also says: "...if you set ID to a 15-character value, Apex automatically converts the value to its 18-character representation." In my example, where I set the ID to the 15 character value it should have converted it to the 18 character equivalent that should have been equal to the 18 character version retrieved via the SOQL call. That's why you normally can safely compare 15 and 18 character ID variables. It also says "ID comparison using == is case sensitive, and does not distinguish between 15-character and 18-character formats" which is a bit vague in this context. – kibitzer Jun 10 '13 at 4:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.