Dummy values are unnecessarily stored in DB

The attached patch does as I proposed above to avoid storing actual values. I expect I could probably try and use D7.22's new field_info_field_map() function to get fields on entities of the addthis type, but I've this patch does this the old way for now, if I get chance I'll post a 7.22 version that will also be backwards-compatible.

Personally, I'd rather see a simpler value than 'Dummy value' used in the various places that a dummy value is needed, such as TRUE but at least 'Dummy value' makes it more obvious what the code is doing.

Since no data is needed to be stored with this patch, it would be ideal if we could even stop the SQL backend creating field tables, however there are no hooks run during field_create_field() that could allow this. There is hook_field_create_field() but this runs immediately after creating those tables, so I guess we could remove the tables but that might create more problems anyway if other modules try to access those tables (especially since the tables would be listed under the storage part of what's returned from field_info_field() on one of our fields.

If it were possible, an alternative would be to use a different storage backend for the field (e.g. the dev/null field storage backend supplied with http://drupal.org/project/devnull ?!) that stores no data for a field, and then only hook_field_storage_pre_load() would be necessary to actually 'load' values into entities. However, while storage backends can be specified as part of the $field parameter given to field_create_field(), this can't be set for all fields of a certain type, which would be ideal. Instead, we would probably have to monkey with the code around field_ui_field_overview_form_submit() to change the submission handler(s) on the fields UI form or something similar as I can't see any other way to do that.

I think we can probably leave the field tables as they are, as neither of these solutions feel ideal. Any other ideas?

All this has really caught my imagination, particularly as I have been thinking about display-only fields like this for a while. Core currently provides these as 'extra fields' with hook_field_extra_fields(), but these don't have formatters, only the 'visible'/'hidden' setting and are a bit of an afterthought but could be ever so useful if given a bit more love/exposure in the community.

Personally, I'd love to see a more developed fields system that incorporates hook_field_extra_fields() 'extra fields', so that field types could only do one or more of the following:
1. Store values (i.e. they have a hook_field_schema())
2. Load values into entities (that could then be cached -- i.e. they implement hook_field_load())
3. Display values (i.e. there are formatters for the field type, or some kind of flag in the hook_field_info() field type definition that allows a fallback, replicating the simple existing 'visible' setting for 'extra fields')

So currently, core field types do all of those three parts, while hook_field_extra_fields() 'extra fields' only do the display part. I expect there are use cases for storage-only fields, or 'computed fields' that would be load-and-display-only fields.

Anyway, I'm now getting well off-topic, but I'd be interested to hear any thoughts that the addthis module's developers have had around this subject in developing the 7.x-4.x branch, and why the current route of using a field storing dummy values was chosen ahead of perhaps using/extending hook_field_extra_fields() 'extra fields' since they are designed for display-only 'fields'.

The attached patch uses D7.22's new field_info_field_map() for better performance when available (and still falls back fine).

The points I raised in comment 2 above are still open for discussion, this tweak merely improves the things already happening in my original patch.

Wow, does the hook_field_prepare_view() get invoked even for all empty fields on a bundle? Then yes please use juampy's patch!

I totally didn't know that, and thanks for adding the comment to the hook's API documentation.