I ran into a situation today where a data table row object was taking extra time to realize that a column did not exist in it. This all may be the way it’s designed, but it surprised me so it might be useful for others, too.
What worked the way I expected
Grabbing an existing column from the row object in the client was quick. On the order of 0.003 seconds. e.g. row['test']
Grabbing a column that was not part of the q.fetch_only argument required a round trip to the server, taking on the order of 0.1 seconds. e.g. row['data']
Checking to see if a column was in the row using in was very quick (usually measuring at 0 seconds), whether the column was there or not, and whether it was part of q.fetch_only or not. e.g. 'foo' in row
That last seems to show that the row object has some built-in knowledge of what columns are available, even if they’re not fetched.
What did not work the way I expected
Trying to actually fetch a column that does not exist took a round trip to the server. e.g. row['foo']
This even though the row object could tell me the column wasn’t there (using in) without a round trip.
The moral of the story
If you’re writing code that may need to work with different types of rows, don’t rely on the NoSuchColumnError exception to tell you if a column exists or not. Use in instead to avoid the server round trip.
I ran into this in some code in a repeating panel row template, where there were two server round trips being made to tell me that the columns didn’t exist. 0.2 seconds per row template times the 10 rows in the data grid added up to 2 seconds of delay per page that was totally unnecessary.
