Query results with a single result doesn't create an array of records
Closed this issue · 8 comments
SFDC will always return fields called records in the SOAP response. Using this nomenclature, I would assume that I would always get an array of things, even if it's of length 1. I don't know if this is standard in XML or SOAP, but it's rather annoying that I can get either a Hash or an Array from records depending on the length.
It looks like from your XML parsing that this was on purpose. I'm wondering what the motivation for that is though. Personally, I'd want to be able to call .each on records and always have it do the same thing, but clearly .each on an array of records and .each on a hash that is a single record will do two very different things.
Can you explain why this is implemented like this? To me... it seems broken.
Hi, Brad.
If I remember correctly, back in the day the only way to know whether SalesForce was returning a single thing or a collection of things was whether or not it gave us back multiple tags with the same name. The low-level parsing code had no knowledge of what specific tags SalesForce would be returning, nor what types of data would be in there (with a minor exception for the baffling multiple identical <sf:Id> tags, added later).
--Ian
ya their XML structure is a bit odd for sure. They do return a size attribute though on records. That brings up another issue though. No numerical or boolean fields are parsed as such. They always come back as strings. I'm not particularly familiar with XML best practises, but I would assume they should actually be returning the types of each node, but this isn't the case for any numeric or boolean based nodes that I've seen. Some intelligent parsing might be able to fix all this though.
Hey Ian,
I'm wondering if you can recommend the best course of action for updating this library. We're making use of it extensively, but have a lot of defensive code that deals with a few of the parsing oddities (mostly due to SFDC's weird API). Some of the things that have tripped us up include:
- Id fields returned as an array
- Single records being returned as a hash instead of an array
- no parsing of numerical or boolean fields into the appropriate type
We (and I think most people) use Nokogiri for parsing the XML and I'd be happy to make the changes to resolve these issues there, but I'm not sure how you'd feel about the parsing returning different results for different parsers. I don't really know any of the other parsers and don't care to really look into them at all. Should I just use my own fork? Or would you be satisfied with Nokogiri returning results that most people would expect.
Hi, Brad.
Thanks for taking a deeper look at this. The hardest part is the spec--which you've done--and updating the first parser. If you've got time to do the Nokogiri flavor in your fork, I can pull it in and adapt it to the other parsers. It still feels a little weird special-casing the parser to do something different when the tag name is record (for item 2), but I'm slowly coming around.
(Thinking out loud here) We'll be changing the data format returned to our consumers, so we should probably roll the version number to 0.9.
I agree, it's less than ideal relying on the records tag. But I'm not sure of a better way to do it. Another thought was to check for a size in the siblings, but I don't know if that's really any better. That branch actually has the nokogiri implementation as well and it passes all the tests. See this commit.
The one thing I'm not sure about is the Integer parsing. I don't know if rescuing from an exception for each node that isn't an integer would have any performance ramifications. To be honest, the numeric/boolean parsing is kind of secondary, I think the most important issues are the Id field return as an array and records sometimes returning a hash and sometimes an array.
At long last, I've merged your improvements to the Nokogiri SOAP response (thank you!) and ported them to the other three implementations.
oh nice! many thanks.
On Wed, Aug 1, 2012 at 2:06 AM, Ian Dees <
reply@reply.github.com
wrote:
At long last, I've merged your improvements to the Nokogiri SOAP response
(thank you!) and ported them to the other three implementations.
Reply to this email directly or view it on GitHub:
#19 (comment)