I am new to d7 and I am writing an install script. This install script needs to create a content type (I've done that) and then create lots of fields that are used in this.

The problem I have found is that d7 automatically creates lots of tables for each field. Considering I will have something like 60+ fields per content type, this isn't very practical.

How can I code into my .install file a way of making all these fields be in a single table e.g. |ID|value1|value2|value3| instead of 3 tables for value1,2,3

Thank you.

1 Answer 1


Short answer: You can't.

As consumer of the Field API you don't have any control on the SQL schema when using the default field storage. The Field API however, allow usage of different field storage on a per field basis. It seems that the Per-Bundle Storage module aims to provide the feature you want. But it has no release, only code in its repository. Another solution is to switch field storage for your content type to a separated MongoDB database.

  • I can't seem to find the code for the per-bundle storage. I'm not 100% sure, but I don't think that having the MongoDB database would be acceptable on this project. I have actually seen a module that did make this work. The commerce module requires the address module for customer's addresses. That creates a field with many columns in it, but I can't work out how. It doesn't just create a table via the hook_schema, it is classified in the field_data part of the database. Any ideas???
    – Terry
    Commented Oct 5, 2011 at 11:31
  • It does it by declaring its own field type with its own schema. Just skip Field API fields, and create columns for what you need. Or investigate the "Properties" module. When it comes to Field API, the answer depends on your use case. And forget about Per Bundle Storage, it's not a good solution (even if it was completed). Commented Oct 5, 2011 at 13:37
  • I noticed that the address module has a schema created, but I couldn't work out what it was creating. That does make sense though. Could you explain what you mean about the "Just skip Field API fields, and create columns for what you need."? I am extremely new to drupal, even though I've been programming for years, and I am running around in circles at the moment trying to learn 1000 things at the same time. If you have any good links, could you share them with me please? Examples would be especially appreciated. Thank you.
    – Terry
    Commented Oct 5, 2011 at 13:46
  • Regarding address field, an address is a separate entity, the address field then is just a refernce to an address IIRC. If your fields (or most of them) are just simple textfields, then Properties (drupal.org/project/properties) might be an option, yes. It basically exposes an unlimited (more or less) key/value storage as a single field. One of the reasons for that project is that having a large number of fields does not scale, the complete field config is loaded on every page and it blows up field, schema and views caches (at least).
    – Berdir
    Commented Oct 6, 2011 at 2:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.