Using the Feeds module, I uploaded a mailing list file in csv format containing custom content type fields containing typical name and address information. The records for "city," for example are contained in a table called "field_data_field_city". Using the UI for either the 7.x-3.x-dev or 7.x.3.0.-alpha versions of views, when click on Arguments and Filter, the drop down lists produce, s expected, an entry "Fields:City (field_city) - value". But when I click on Fields, the drop down list produces an entry "Fields: City", but no entry "Fields:City (field_city) - value".

Am I missing something obvious? But as it stands, I can't figure out how to create a view of the values stored in my mailing list fields.


Why can't you use "fields: city" as a field? It provides every kind of information you need.

Additional you can select a unformatted formatter, so it just prints out the "raw data".

If I use, say, the field representing city information and call for unformatted output, Views generates the following SQL statement:

SELECT node.nid AS nid, 'node' AS field_data_field_city_node_entity_type
{node} node

Sorry, but this doesn't cut it. It needs to generate a statement that uses the variable "ffield_data_field_city.field_city_value."

While I can easily pull the right information with a garden variety SQL select statement, but I can't find any way to do it with Drupal's views UI.

In short, I'd like to know where you're finding "every kind of information you need."

Why does it need this?

You will see it's possible to show the field without it. Views load's the fielddata based on the entity type of the item.
The reason for this is, that you can't render a field without the full entity data.
This was detailed worked out in various issues on

There is a way to add the statements to sql, but not via ui.
Therefore you have to add 'add fields to query' via hook_views_data_alter

Thanks for the info on hook_views_data_alter.

While I don't want to sound ungrateful for your assistance, the idea of having to use hook_views_data_alter to generate a proper SQL query strikes me as something akin to a Rube Goldberg device. Given that Drupal uses relational databases, it seems fairly obvious to me that Drupal ought to allow its users to design queries simply by writing straightforward SQL code. When one looks at all the "handler" statements in an exported Drupal view, the only word that comes to mind to this old database guy is "kludge."

But why do you even need the value?
Due to the way the entity api works in Drupal, the sql value is not used for showing the field (it is fetched separately before render through entity_load()), so there's no need to add it to the query as well.

A handler is more than just a single database field. In theory it can be much more.
Take for example taxonomy: all terms, which can load all terms of a single node.
Therefore you have to run an additional query.

For fieldapi fields you have the same problem once you want to render a field. It needs the full $entity, not just the field values, which could be queried from the database. So you can't get everything you need with just a plain sql query. You need to invoke the field system.
Additional if you want to have multiple fields per result row you also need a second sql query, like in the taxonomy example.

The entity api design is like this, you can call it kludge or not, but for views it's just not possible to act different.
The feature to add the field to a query just allows use cases for modules like searchlight, but you don't need it.
If you need the raw value you can get it, if you really want.

Every kind of specific theming should be done as formatter. The advantage is that you have full access to $entity :)

Status:Active» Closed (works as designed)

Just an FYI, we tried to do it the way you want, where we added database fields to the query anyway. It doesn't work. Field API design makes this prohibitive. It's not our fault, we can only work with the APIs we're given.

Honestly, modules should never have been looking at the raw data. Instead, style plugins now get a 'rendered fields' array, which contains the output of the field, as rendered, and we simply need to ensure that there are the rendering options necessary to get raw data for export. Field API is not the only system that we can't actually just fetch raw database values. AS an old database guy, surely you understand that when trying to retrieve data in a many::one relationship on an object, such as tags or user roles or the like, you can't simply add it into the query because that would cause row duplication. You have to go an extra mile to retrieve this data. Views goes that extra mile by performing secondary queries. This data, also, won't end up in the $result object, because it is the result of a different query.

What we're seeing here is not a bug, it's the design of the system, working around the limitations we are given.

Yes, I see an entry "Fields:City" in Views UI field list and a corresponding entry for a custom content type field named "field_data_field_city_node_entity_type" in Views SQL query, but the query does not pull any value information for that field, just blanks, even though there are valid entries in the underlying database.

So your actual problem is that the field is not displayed? You get no output?

Found the source of my problem: the query will not work unless the node ID field is included in the query.