Apex Code Development You need to sign in to do that
Don't have an account?
cfaherty SOQL relationship.Name inconsistency
Are there any plans to improve the relationship.Name with query() or retrieve()? As it is right now, there is no guarantee that an sobject has a .Name, and in fact even if there is a designated "name" field it may not work with the .Name alias. Case.Name (error) versus Case.CaseNumber for example.
I will explain the impact. Mobile application, and displaying an sobject. Very efficiently any sobject *could* be rendered if you mobilize describeSObject/describeLayout for it, issue a retrieve() with relationship.Name for all lookup fields. However, since there is no guaranteed .Name for all sobjects, one must mobilize the describeSObject for each and every lookup in the root sobject, just so that it can build the retrieve() with the proper relationship.Field to render. Terrible waste of resources.
The funny thing is that, in fact, there appears to be core code which forces relationship.Name to work with polymorphic lookup fields. You can see that Event What.Name works fine despite some of the sobjects not supporting relationship.Name in nonpolymorphic lookup fields. I'm left to wonder why it works there and not in the regular lookup fields.
Anyhow, I wanted to go on record and request that relationship.Name should always work in query() and retrieve(). It would save a tremendous amount of CPU cycles and traffic on the wireless. Good for the environment and all that.
describeSObjects (plural is important) exists to minimize the cost (and number of round trips) of having to figure this out. We currently make the decision to not guess at what a user means and just fail fast when it's not obvious (like when an sobject doesn't have a name field and the users requests it).
You're right that we do special work to support the Name field on polymorphic relationships. This work isn't done for every sobject.
Feature requests should be created as new ideas on the IdeaExchange.
Thanks for your reply. DescribeSObjects() is good, any plans for DescribeLayouts()? I use them on-demand.
Recently I implemented an SOSL client and ran into similar .Name issues. DescribeGlobal() is used to develop a list of potential sobjects to SOSL search, however the inconsistent .Name issue prevents an efficient request of render fields. Potentially hundreds of sobjects to search but it requires at a minimum a two-step retrieve in order to render results.
I had to crop the SOSL search to a short list, a list for which I would be OK with having a DescribeSObjects(). The list is augmented with some custom renders which have hard-coded knowledge of some sobjects. It's kinda sad. It would be nice to get renderable results for any sobject from a single SOSL request.
I suppose my situation could be remedied by either increased .Name support, or perhaps DescribeGlobals() having an array of name fields for each sobject.