Apex Code Development You need to sign in to do that
Don't have an account?
jhart bug: Database.getQueryLocator requires namespace prefix
Note I'm not positive the subject of this post is the true reason for the bug. The other possible explanation is:
Dynamic SOQL requires namespace prefixes when called in global context
Anyway, the bug is:
Our managed package occasionally uses Dynamic SOQL. In one case, we have a controller that uses Database.query() without any namespace prefixes:
Database.query('select CustomField__c from CustomObject__c');
In another case, we call Database.getQueryLocator() (as part of a Database.Batchable implementation). That query also does not include the namespace prefix:
global Database.queryLocator start(Database.BatchableContext bc) {
return Database.getQueryLocator('select CustomField__c from CustomObject__c');
}
All of this works in our DE org, but once packaged & deployed, only the first one works.
The second ("getQueryLocator") throws an exception:
Developer script exception from iHance : 'i.Maintenance' : common.exception.ApiQueryException: No such column 'CustomField__c' on entity 'i__CustomObject__c'. If you are attempting to use a custom field, be sure to append the '__c' after the custom field name. Please reference your WSDL or the describe call for the appropriate names.
I'm not sure if the bug is that getQueryLocator() requires the namespace prefix, or if Dynamic SOQL methods called in the global context do. Without re-packaging everything to create a test case, there's no way for me to tell.
Salesforce support - I've created case 03501471 to track this issue.
Note - salesforce support has accepted this as a bug and are working on it. The workaround is simply to include the full namespace in your getQueryLocator() statements.
SOSL used to have a similar bug, back in the day, where Custom object names required their namespace. Not sure if that's fixed or not as all my SOSL still has the namespace in it =)
From salesforce support engineers:
Thank you for contacting us regarding your namespace issue. Our engineers are actively working on this issue. However, the workaround at this point in time is to explicitly reference your namespace in the query.
All Answers
Note - salesforce support has accepted this as a bug and are working on it. The workaround is simply to include the full namespace in your getQueryLocator() statements.
SOSL used to have a similar bug, back in the day, where Custom object names required their namespace. Not sure if that's fixed or not as all my SOSL still has the namespace in it =)
From salesforce support engineers:
Thank you for contacting us regarding your namespace issue. Our engineers are actively working on this issue. However, the workaround at this point in time is to explicitly reference your namespace in the query.
As of Summer '10 we're getting the same error only this time with Aggregate queries. The work around is the same, include the namespace prefix for all fields in a Dynamic SOQL query.
Interesting ... Aggregate queries using dynamic SOQL still work fine in our released (managed) app. Haven't tried developing any new ones on Summer '10, however.
@jhart - did this get resolved for you?
I'm seeing "Fatal_EERROR|Internal Salesforce.com Error" immediately after the Database.getQueryLocator(string) method files, and it exists the Aggregations clause.
@jkucera,
I don't know if it was ever fixed - the workaround was right simple, so I haven't messed with it since then. I don't run regressions on these bugs, so I never find out when they are fixed as there's no process in place to inform ISV partners of bugfixes =(
-john
Yeah-the lack of bug transparency is frustrating. I couldn't find the bug in our bug database so I can't confirm the status.
I ended up using your method to fix the issue, but wasted 3hrs as I thought I only needed the namespace on the custom object, not on each of the custom fields in the query as well.
The partner portal case still exists - 03501471 aka 50030000008vekhAAA - but I don't know the internal bug number. If you want to dig further, hit me with a PM and I'll let you know which Tier 3 support person responded to the case (which doesn't appear to be in the case history).
Amazingly, I just banged my head against this *again* and forgot all about it for an hour. I even opened a new case ... sheesh.
So, no, the bug is not yet fixed as of Summer '10 release.
For what it's worth, I'm wasting 2hrs of my time working around this for the 2nd time as well. I'll continue to hound the Apex team to fix this.
It's pretty dumb that Apex doesn't recognize namespace_ObjectName but namespace is required for batch apex query locator, so I have to do some ninja moves to make tests pass that never failed before.
any news on the bug? has it been fixed?
Just checked on this. Bug has not been fixed yet, so the workaround is still neccessary for now.
Anybody know if this has been "fixed" in Summer '11. We've got packaged batch Apex code that WAS working on Spring '11 that is no longer working on Summer '11. Started getting this error after the Summer '11 upgrade:
Seems like maybe they "fixed" something in Summer '11 that broke the code that worked around this bug in the first place.
What instance (NA1, etc) are you getting this on? Or is it on a developer preview of Summer '11?
(I'll admit to not paying much attention to the upgrade schedule, but your issue makes me think I should!)
NA7
Release happened over the weekend for Na7 :)
In regards to the original issue, not fixed yet sadly.
In regards to this new issue with summer '11, I've actually been helping one of my colleagues to reproduce this. If you have a simple replication scenario already put together, create a case in the parter portal with the steps and put the case # here!
FWIW, we have many customers on NA7 running code with the workaround in it, and we haven't seen this error (yet). I'll keep my eyes peeled, though...
EDIT: actually, we don't call getQueryLocator all that often, so it's possible our NA7 customers haven't run any code that calls it yet. I'll poke around in a bit.EDIT 2: Actually, I forgot - we call getQueryLocator as part of a scheduled Apex job that runs hourly. It uses the namespace prefix when querying a custom object in the same package, just as the workaround specifies:
Database.getQueryLocator('select Id, i__UseAA__c from i__AAUserPrefs__c ....So we definitely have many customers running this code frequently, and we aren't seeing the error. Just to be sure, I just launched the apex job for one of our NA7 customers, and it executed fine.
(phew!)
Still experiencing the issues on multiple instances post Summer '11. Please add me to the bugfix notification list!
Hi,
did you get any feedback on this. I'm having similar troubles when executing dynamic sosl from a test method on a managed package with namespace.
regards!
same here...really looking forward to this being added in.
I don't think you can run SOSL in test methods, period. I believe this is by design. This is an excerpt from the Apex Developer's Guide:
To ensure that test methods always behave in a predictable way, any Salesforce Object Search Language (SOSL) query that is added to an Apex test method returns an empty set of search results when the test method executes. If you do not want the query to return an empty list of results, you can use the Test.setFixedSearchResultssystem method to define a list of record IDs that are returned by the search. All SOSL queries that take place later in the test method return the list of record IDs that were specified by the Test.setFixedSearchResults method. Additionally, the test method can call Test.setFixedSearchResults multiple times to define different result sets for different SOSL queries. If you do not call the Test.setFixedSearchResults method in a test method, or if you call this method without specifying a list of record IDs, any SOSL queries that take place later in the test method return an empty list of results.
Sorry, maybe I misunderstood. Did you mean dynamic SOQL? or SOSL?
You understood correctly, I meant SOSL.
We are using the Test.setFixedSearchResults it's just that we have the app packaged and behaving ok until I added the namespace.
Either way I expressed myself wrongly. I run into this behavior about the namespace because a test method was failing. And after some time of debugging and researching I found this thread and wanted to know if there are any update.
So the situation is :
I have some dynamic SOSL queries that are failing becouse I'm not explicitly adding the namespace.
Hi Andream,
The SOQL issue has been resolved but it sounds from your description like the problem may still exist for SOSL. Best next steps would be to open a case through the partner portal so we can take a look at it, should be pretty easy to replicate.
Witnessing the same issue as reported by 'andream' related to Test.setFixedSearchResults.
Looks like Test.setFixedSearchResults call when used in testMethod for testing SOSL query needs explicit namespace prefix for Object being queried.