Guest Post: structDeleteAt() doesn’t play nice with webservice returns
Sooner or later, we all experience it. The chill runs down our spines, and we stare at the computer screen, not knowing whether to cry or curse at the cryptic error that rears its ugly head and laughs at us.
What I’m referring to is, of course, coldFusion deciding that it only wants to do things a certain way, regardless of how you *think* the process should go.
Not too long in the distant past, I encountered such a beast, and will relate my story now.
The task was simple: connect to a webservice, and display the results. As the project progressed, the rules changed slightly – now I needed to grab the results, and filter out any that didn’t belong based upon a criterion set. Never you mind that usually, the web service would be changed or manipulated so that a parameter or two could be passed in & perform the filtering on the server side. That wasn’t a possibility in this case, and wouldn’t prove to have been near as much fun.
The rumblings and mutterings from the nether world began when I attempted to loop over the results and filter out any which didn’t fall within the specified criteria. Normally, this would just involve a cfif tag to test each set of returned data to decide to display it or not. The crux of the problem was that before entering the loop, the count of how many records were returned was displayed. Depending on how many records were excluded, this count could be, and was, way off of the actual records that were displayed.
My initial theory was to loop over the record set returned from the webservice, and use a structDeleteAt() call to remove any records which did not match what I was trying to display.
*KABOOM*
ColdFusion refused to delete the record. I tried everything. Setting the value to empty, using a Javacast to set it to null, even copying the returned result set, and working with the copy.
None of it worked.
ColdFusion liked how the returned result tasted, and wasn’t about to let go, not for any amount of cajoling or cursing at it.
Finally, defeated, I tried a different approach. Instead of using any trickery, or established CF functions or methods, I decided to bring a howitzer to this knife fight.
The answer lies in the code below.
<cfloop from="#ArrayLen(serviceReturn.contacts.anyType)#" to="1" step="-1" index="i"> <cfset tmp = serviceReturn.contacts.anyType[i] /> <cfset tmpPaidThrough = tmp.getPaidThrough() /> <cfif EXPRESSION_TO_CHECK_AGAINST > <cfset tmpInsert = arrayappend(session.searchResults,serviceReturn.contacts.anyType[i]) /> </cfif> </cfloop>
To explain:
- loop over the record set returned by the webservice.
- set the record to a temp variable, and get the part that we want to check against (in this case, paidThrough)
- if the record passes the test, append it to a new variable (session.searchResults)
- note that I have gone from the end of the struct to the beginning, but I believe it would work either way
Then, in the display portion of the code, instead of using the returned record set, we use the new variable we set up that only has the records in it that have passed the test for display purposes.
*VOILA*
ColdFusion, realizing that it has been defeated, slinks off to haunt some other poor soul.
I’m not entirely sure why CF would not relinquish the record of the returned set. In discussion with other developers, we reasoned that perhaps since the return was a struct of struct of structs, somewhere in the vast underlying java mysteries, the pointers could not be moved or deleted, so CF did not want to delete the data. Copying the returned structure resulted in a structure of the same design, so CF wasn’t able to delete from a copy any more than it could from the original record set.
So there you have it. Wipe the blood off your sword, hoist a beer, and move on to another realm, full of it’s share of demons and battles.
-Dave
