Field names require namespace prefix unlike other Apex code

[GoogleCodeExporter]

When working in a development org that has a namespace prefix defined (cvc in 
this case) that prefix needs to be included 
in the field name in calls like this:

ESAPI.accessController().insertAsUser(claim, new String[] {'cvc__Status__c'});

All other Apex code (e.g. SOQL) remains unpolluted with the prefix as that is 
really a separate attribute and may change. 
And more importantly, the code will not run in any other development org such 
as the org that sf:deploy is used to do 
continuous integration deploy/tests into. (See 
http://force201.wordpress.com/category/continuous-integration/ for an 
example of such a setup.)

So please consider one or both of these possibilities:

A) Adding the prefix internally in the implementation so the calling code 
remains clean and people do not have to 
implement their own code to do this and make the ESAPI calls even more verbose 
by wrapping all the field names in the 
resulting utility.

B) Given that you are already consuming the 10 describe calls limit to get 
other information you need, provide methods 
which do not require the field names to be supplied. (Or is there no way of 
avoiding hitting "SObject row was retrieved 
via SOQL without querying the requested field" errors in this case with your 
design?) As the API stands you are adding 
yet another case to the DRY principle violations that Apex imposes and also 
potentially (if other steps have been taken) 
stopping managed package code from working when custom fields are added.

Original issue reported on code.google.com by keith.clarke.claimvantage@gmail.com on 27 May 2010 at 12:06

[GoogleCodeExporter]

PS To support fields from various packages, perhaps the auto-prefixing should 
be 
defined with e.g. a Strategy interface.

Original comment by keith.clarke.claimvantage@gmail.com on 27 May 2010 at 12:30

[GoogleCodeExporter]

Thanks for reporting this issue, we will be looking in to this shortly.

Original comment by apex.es...@gmail.com on 1 Jun 2010 at 5:00

[GoogleCodeExporter]

Original comment by apex.es...@gmail.com on 1 Jun 2010 at 10:07

• Changed state: Started

[GoogleCodeExporter]

As of r42 we added insertAsUser and updateAsUser functions that accept a list 
of 
Schema.SObjectField instead of strings. This avoids using the sObject fields 
member 
variable all together, and thus should have no impact on limits aside simple 
code 
execution. 

In addition because the user can provide the Schema.SObjectField it should 
bypass 
the namespace issue too assuming you can access it from within your code 
properly 
already.

Please let me know if this solves this issue so I can close it.

Original comment by apex.es...@gmail.com on 3 Jun 2010 at 2:40

[GoogleCodeExporter]

Yes i think it does. thanks.

Original comment by keith.clarke.claimvantage@gmail.com on 4 Jun 2010 at 7:27

[GoogleCodeExporter]

Thanks for your feedback.
Closing this issue.

Original comment by apex.es...@gmail.com on 4 Jun 2010 at 6:28

• Changed state: Fixed