I have a product content type on Drupal 7 with >100 fields, and there are >7000 products, all with several revisions. Our client keeps requesting that we add and remove fields, which is quite painful and takes several tries to successfully complete due to mysql having a conniption.

The go-to strategy has been to increase the RAM on the server, but we are hitting a cost wall and this bothers me as a developer since we are just deferring dealing with the problem.

Comedy Option:

The majority of these fields are specifications which are never related, filtered or displayed outside of the detail view. Could I reasonably create a JSON product_spec field that contains all of these spec fields and write custom modules to display them on the detail/spec screens, allow editing through the API, and allow editing them on the admin interface?

Is there an existing module that does something similar? Would entitycache be a much more practical option?

  • Possible duplicate of drupal.stackexchange.com/questions/121297 - or at least the answers may be relevant. Specifically Clive's answer.
    – rooby
    Commented Jan 28, 2015 at 2:48
  • That is an excellent link, and points out the Examples module which I was not aware of. I do like the idea of a custom field, which would solve many of my performance issues. It still has the problem that when the client inevitably decides to add or remove a spec I'll have to do some update schema stuff, which I'm hoping to avoid. Commented Jan 28, 2015 at 17:36
  • What do you mean MySQL having a conniption? We need a more precise error message or symptoms or something.
    – user49
    Commented Feb 3, 2015 at 21:37
  • @chx I really wish I knew why it was having a conniption :) I enabled the slow query log and it showed a bunch of very complicated very slow queries (mostly involving the cache) I believe mysql was having trouble with locks and updating tables, meaning fatty queries were blocking other fatty queries until it timed out. The fix was to delete old revisions (10,000 revisions, ~1.5 million rows gone) Commented Feb 3, 2015 at 23:42

3 Answers 3


This is really interesting and, whereas the suggestions in the other question are really good as pointed out by the comment above, I don't really think it's practical to give up on the Field UI for this (like mentioned in the other question).

Let me explain:

  • Creating a custom field is really easy, there's a good example in Panopoly Widgets for the dashboard widget, which has a custom field for the Spotlight widget.
  • Creating a custom entity isn't so bad either but creating every single field using Form API should be out of the question

The only plausible solution that I can think of would be to implement hook_field_storage_info() and create a new Field API storage backend that uses a better table configuration.

If you look at field_sql_storage.module in core, it's a pretty concise module that provides the one field per table storage backend, I'm sure with some hacking around you could create a new backend that uses one table per entity and stores each field in a new column there (kinda like D6 CCK with cardinality 1 fields).

You would have to be constantly altering the table schema whenever new fields are added (which should be fine). This might be the place to do it: hook_field_storage_create_field().

It's pretty theoretical but I think it'll work... the beauty of this approach is that you can still use Field UI for everything as usual.

Caveat: You're gonna have to figure out how to handle complex fields or multiple cardinality (hint: more columns?)

PS - Knowing of the frequent schema changes, you wanna make sure you have backups/concurrency for peace of mind.

Good luck and if you get this working I'd like to see it! :)

  • drupal.org/project/pbs is a proof of concept for one table per bundle. Noone picked it up. Perhaps it's not as easy as you think nor is it desirable, I think.
    – user49
    Commented Feb 3, 2015 at 21:36
  • I never said it was easy! Just there looks like there's a lot of stuff to explore... nice module, wasn't aware of it. And I definitely don't think its desirable either, that's the OPs problem :)
    – Alex Weber
    Commented Feb 4, 2015 at 0:49

Why not solve it with custom fields, grouping similar fields into one compound custom field and trying to keep a sane data model (ex: not 'all the things in one field'). There are many tutorials on how to create custom fields and it's quite easy.

  • Yes, this is the sane and practical option. I'm just seeing what is out there. Commented Feb 4, 2015 at 17:49

I would give the Dynamic Properties module a try.

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.