Nope, sorry. Static columns are not supported either. SOQL has a limited mapping to SQL. The objects are defined by the wsdl contract and creating arbitrary fields via a static column or a function would cause a dataset to be returned that could not be mapped to the wsdl defined shape.
Good point, I can appreciate that the standard WSDL would not support arbitrary columns - however the Partner WSDL would accomodate this if I understand the issue correctly?
Do you think this would be a future consideration for SOQL with the requisite that only apps using the Partner WSDL could correctly handle the result set?
First, yes, the partner wsdl implementation could handle something this like this, with caveats. But, for static fields, it feels like a frivilous (sp?) use of bandwidth. Suppose my static column is 50 chars. wide and I return 1000 records. I've just increased the size of my soap response by what could be a fair percentage. I'm not sure we want to populate an arbitrary number of static columns across n records. Seems just as easy to augment the return with the static fields.
I am fairly confident that we will try to avoid having SOQL that is appropo for one wsdl versus the other. Support and testing gets a bit overwhelming.
Your logic and arguments certainly seem sound to me - I definitely appreciate your time in responding with detailed explaination.
This was just a left over convenience feature I've grown used to in traditional 2-tier RDBMS solutions where bandwidth was not as large of a concern. I'll work on adjusting my assumptions and perspective.
Do you think this would be a future consideration for SOQL with the requisite that only apps using the Partner WSDL could correctly handle the result set?
Thanks -
Todd Hardin,
Customer Systems Inc.
I am fairly confident that we will try to avoid having SOQL that is appropo for one wsdl versus the other. Support and testing gets a bit overwhelming.
This was just a left over convenience feature I've grown used to in traditional 2-tier RDBMS solutions where bandwidth was not as large of a concern. I'll work on adjusting my assumptions and perspective.
Thanks again.
Todd Hardin,
Customer Systems Inc.