Apex Code Development You need to sign in to do that
Don't have an account?
GlennW Return from query using Partner API
When I run a query using the partner api (v2.5) requesting a set number of fields from an object the first xmlElement in the array of elements that is returned has a local name of "type" and it's innerText is "Account" (or the name of the object that I am querying).
Is this by design?
Is there a way to suppress this as it leads to confusion when I am accessing a task object that also has a field named "type"
GlennW
Hi GlennW,
The type element is by design as it is part of the sObject definition. It is in a difference namespace than the Type field of an object. I can understand though that it could be potentially confusing. Each element in the XmlElement array that is returned on the Any field has a name attribute and a localname attribute. The sObject type has no namespace in the name attribute and is lower case. This should help avoid confusion.
A more puzzling question is why that lower case type is in the Any field at all. It should be serialized to the sObject.type field and not be in the Any field at all. The Id for instance is at the same level of the dom as the type and Type, but is properly serialized into the sObject.Id field. I'm not sure why this is happening, or not happening. The design was that the type that contains the name of the object type that you queried for would be a named property of the sObject. Another question that might be asked is, why is this on every record anyway and not at the queryResult level? You can only query on one object type per call so it could be argued that it belongs to the queryResult object.
I will raise these points with our engineering staff and see what comes of it.
Cheers
Dave;
I have also found that the sObject.type is often left blank on a return from a query. I'll run a few more tests and give you some examples on how to replicate the error.
Also; I've just completed my Mass Insert/Update tool (insert or update any salesforce table from xls,csv or mdb) and my Account de-duplication tool for v2.5 of the salesforce API. If you know of any users that would like to beta it feel free to have them send me an email glenn.wilson@quotegen.com
Cheers;
Glenn Wilson
Hi GlennW,
Yes, the sObject.type is not being loaded properly by .Net from the SOAP message. It is instead leaving the type in the sObject.Any array. This appears to be a .Net only issue as I tested it using Axis and the sObject.type value was properly placed in the sObject.type field and excluded from the sObject.Any array.
We will be trying to figure out why .Net is handling the Id field properly and not handling the type field properly. A patch should be forthcoming. Don't waste any more time on it, just use the logic that I mentioned in my previous post.
Cheers
All,
The issue with .Net and the sObject.type field has been resolved and has been published.
Cheers.
I had developed to the bug you have talked about not knowing it was incorrect. I will have to fix some of my code to handle this change. My error resides in the .Any array being modified. Are you sure this change will stay reality or will you have to back the change out to handle all of your customers?
-- Glenn
Hi GlennW,
This change is a change to match the spec and the wsdl. The call now functions properly and you can be confident that it will not revert.
Dave;
I think you were responding to Glenn (Not GlennW)....
I've already modified my code to match up with the changes and I'll be posting it later today. One thing that would be nice (if you could put it on the wishlist) is to have the Where statement cover parent objects. For example WHERE name = "Bob" and account.name = "IBM"
Cheers;
GlennW
Hi GlennW,
Sorry for the confusion. The wish list item you mentioned would be nice, but it is not a simple thing to do. As of now, server side joins are not supported (this is required for the type of criteria you mention). The reason is that we have not, as yet, figured out a good way to guarantee that a users query that has server side joins will "behave" and not negatively impact all other users. If we give you one ss join, you'll want more. As the number of ss joins increase the cost of the query increases tremendously. So, the issue is one of convenience versus service levels.
We are trying to solve this issue though.