All Ideas

Idea Details

Post an Idea

This idea has been delivered and can no longer be voted or commented on. If you’d like to add to this conversation, please post a new idea.

1,170 Points voting closed

Delivered in Spring 21

Steve Bower

Select * capability

Data Import & Integration

I'd like the API to recognize the wildcard * so I don't have to issue a Describe call and build a list of fields whenever I want an object loaded with all it's fields. Discussion: : There are many instances where I need all the fields of a object. For integration purposes, or in order to clone the object. Select * is a long standing wildcard capability that just makes a lot of sense to have. The logic of not having it because it will be abused and used casually is reasonable. Perhaps the wildcard'ing capability can be turned on through a header option which is off by default, that way you have to really want it in order to use it? Thanks, Steve.

· Flag

Latest Comment from Salesforce

Kris Harrison - 8 months ago

A new FIELDS() function is available in SOQL to support definition of pre-defined groupings of fields within query statements, including the option of "ALL". To learn more, please see: https://help.salesforce.com/articleView?id=release-notes.rn_api_soql.htm&type=5&release=230.

Flag

Comments ( 17 )

Sort By

Kris Harrison - 8 months ago

Flag

Kris Harrison - 1 year ago

Hey everyone - I’m the product manager for core data “Enterprise” APIs at Salesforce, which includes query operations and SOQL. We have a new Pilot program open in Summer ’20 for what we’re calling the SOQL FIELDS() Function, which will make it easier to return more meaningful query results with less verbose code. On Thursday 6/25 at TDX20, I’m going to talk about this and few other key API enhancements in detail during the “Do More with Less Code Using Salesforce APIs” episode. Please reach out to your account team at Salesforce to be nominated for the Pilot, and be sure to tune in to the episode to learn more, thanks!

Flag

Gopal Sohun - 2 years ago

Very useful indeed, especially with external api users.
- Flag
Apoorva Singh - 5 years ago

For integration purposes , the calling system can query once and work with buffered data for additional procesing. This would be so much helpful.
- Flag
Anupam Rastogi - 6 years ago

Yes it would be useful.
- Flag
Charles Telles - 7 years ago

I am surprised they haven't implemented such a basic feature. select * is indeed quite handy.

SF bring select * on.
- Flag
Eric Kintzer - 7 years ago

I agree with Keith Clarke's comment
- Flag

Tony Scott - 9 years ago

Without this feature Field Sets are only partially implemented. Consider the scenario where a VF page includes a Fields Set. If an administrator adds a new field to an object and places it into a Field Set the code will break if the field is not included in the select. The only way round this is to use dynamic queries based on a describe call to ensure that all the fields are retrieved. This is a considerable overhead.

Flag

John Hillstrom - 10 years ago

This is a huge maintainance headache for us right now (not having select * ).
- Flag
Josep Vall-llovera - 10 years ago

Well, there's a workaround with 'Schema.SObjectType.[YourSobject].fields.getMap();' and dynamic SOQL query (build String query and then do Database.query();).

Hope this helps! ;)
- Flag

David Mosher - 11 years ago

This is also required when you are trying to clone an object without building into the code the names of every field. Otherwise you end up using a describe to get the list of the fields to avoid making the code obsolete as soon as an additional field is added.

Flag

Kyle Roberts - 11 years ago

I'm just at a loss of words that this was not implemented in the first release. Concerns of abuse should not hinder functionality.

Two years later, IMPLEMENT THIS! How about putting a little less funding in marketing campaigns and add some features for the developers building on this platform?

Flag

Keith Clarke - 11 years ago

The lack of this is a fundamental block to creating Apex code that can be re-used as any code touching the database ends up with its own hard-coded set of fields that as fields are added become incomplete. Even when not trying to create such code, we all waste too much of our lives fixing the "Object row was retrieved via SOQL without querying the requested field" errors.

If you resort to using describe calls to identify all the fields then you are subject to governor limits and lose the benefit of the compile-time checking of non-dynamic SOQL.

I don't understand the argument about the enterprise WSDL - whatever happened to the idea that consumers can just ignore elements they are not expecting - and question its relevance to the in-platform Apex code case where the compiler has a good understanding of the objects fields as evidenced by the compilation checks done on SOQL.

Flag

Ori Price - 12 years ago

Could also be useful when you want to select objects fields dynamically. When you create a generic class that update certain fields (that could be named differently in different objects) you need to select all fields. Currently this can't be done (as far as i know) and you have to do it hard- coded for each object.

Flag

Steve Bower - 14 years ago

Agreed, however for the Partner API this would help a lot and wouldn't require WSDL changes.

In my opinion, if you're using the Enterprise WSDL, and you make a change to an Object, it's your responsibility to maintain the WSDL. After all, what happens now if I *remove* a field or object that an application is relying on. The app will also crap out, although perhaps through an app exception instead of a soap exception. In either case it wouldn't work correctly.

If WSDL compatability is important, then this is more of an argument for doing some sort of versioning in the generated WSDL.

If we had an autoincrement number maintained by the system on Object/Field changes, then we could use it to determine if the WSDL is out of date. The WSDL version number could be sent as part of the header, and if it's ever older than the one stored for that user, it throws an "Obsolete WSDL" error which we could catch and then decide what to do.

Of course this is ugly because not all Object/Field changes effect all users (although perhaps you just track it for the Org as a whole), etc. However I leave that to greater minds.