Skip to main content
Tweeted twitter.com/#!/StackSalesforce/status/562742654988189696
added 14 characters in body
Source Link
Keith C
  • 137.3k
  • 29
  • 218
  • 458

We have some code and SObjects and fields in a managed package that works when executed by other calls in that managed package as your would expect. The code looks like this.

private SObjectField dateField = BenefitClaimed__c.DateOfDisability__c;

public Boolean required(PaymentSpecification__c ps) {
    if (ps.BenefitClaimed__r.get(dateField) != null) {
        // Stuff done in here
    }
}

But this code (that is in a global class) is also executed from a separate managed package, and in that case does not appear to enter the "if" condition. Now if the dateFielddateField was a hard-coded string, I would be very suspicious of a problem because of a missing namespace prefix on the field name. But this seems less likely using an SObjectField token.

A colleague is about to add some debug code and repackage and test some more. But in parallel it would be helpful to know:

  1. Is the namespace prefix automatically added to SOQL defined by the namespace prefix of the class the call is made from (I assume so) or by the namespace prefix of the entry point class of the request?
  2. Is the above code at all likely to break when called rom a separate managed package?

We have some code and SObjects and fields in a managed package that works when executed by other calls in that managed package as your would expect. The code looks like this.

private SObjectField dateField = BenefitClaimed__c.DateOfDisability__c;

public Boolean required(PaymentSpecification__c ps) {
    if (ps.BenefitClaimed__r.get(dateField) != null) {
        // Stuff done in here
    }
}

But this code (that is in a global class) is also executed from a separate managed package, and in that case does not appear to enter the "if" condition. Now if the dateField was a hard-coded string, I would be very suspicious of a problem because of a missing namespace prefix on the field name. But this seems less likely using an SObjectField token.

A colleague is about to add some debug code and repackage and test some more. But in parallel it would be helpful to know:

  1. Is the namespace prefix automatically added to SOQL defined by the namespace prefix of the class the call is made from or by the namespace prefix of the entry point class of the request?
  2. Is the above code at all likely to break when called rom a separate managed package?

We have some code and SObjects and fields in a managed package that works when executed by other calls in that managed package as your would expect. The code looks like this.

private SObjectField dateField = BenefitClaimed__c.DateOfDisability__c;

public Boolean required(PaymentSpecification__c ps) {
    if (ps.BenefitClaimed__r.get(dateField) != null) {
        // Stuff done in here
    }
}

But this code (that is in a global class) is also executed from a separate managed package, and in that case does not appear to enter the "if" condition. Now if the dateField was a hard-coded string, I would be very suspicious of a problem because of a missing namespace prefix on the field name. But this seems less likely using an SObjectField token.

A colleague is about to add some debug code and repackage and test some more. But in parallel it would be helpful to know:

  1. Is the namespace prefix automatically added to SOQL defined by the namespace prefix of the class the call is made from (I assume so) or by the namespace prefix of the entry point class of the request?
  2. Is the above code at all likely to break when called rom a separate managed package?
Source Link
Keith C
  • 137.3k
  • 29
  • 218
  • 458

Are SObjectField tokens safe in cross-managed package calls?

We have some code and SObjects and fields in a managed package that works when executed by other calls in that managed package as your would expect. The code looks like this.

private SObjectField dateField = BenefitClaimed__c.DateOfDisability__c;

public Boolean required(PaymentSpecification__c ps) {
    if (ps.BenefitClaimed__r.get(dateField) != null) {
        // Stuff done in here
    }
}

But this code (that is in a global class) is also executed from a separate managed package, and in that case does not appear to enter the "if" condition. Now if the dateField was a hard-coded string, I would be very suspicious of a problem because of a missing namespace prefix on the field name. But this seems less likely using an SObjectField token.

A colleague is about to add some debug code and repackage and test some more. But in parallel it would be helpful to know:

  1. Is the namespace prefix automatically added to SOQL defined by the namespace prefix of the class the call is made from or by the namespace prefix of the entry point class of the request?
  2. Is the above code at all likely to break when called rom a separate managed package?