problem with cache_form table

I use a nodes with 2 and more referenced products.
After the node is rendered, in table 'cache_form' adds 2 or more records. One record size is ~1MB.

How I can use attributes without this bug?


P.S.: Sorry for my English.

Posted: May 15, 2012


egorbright on May 16, 2012


But on every page (if page contains some product form) refresh the table is bigger and bigger, and records with expired time is not deleted.

Sorry for my English.

P.S.: I'm not use caching ))

dean on July 13, 2012

I have the same issue with "cache_form" the table grows to about 300mb a day which isnt a problem but Cron doesn't clear it. You have to use PHPMyAdmin and clear the table manually, which could be a problem when the site is handed over to the client.

enfreeco on November 2, 2012

Is there anyone who has found a solution to this problem?

Every day I have to manually remove the contents of the table cache_form that has come to be 20GB.

Thanks guys for the great work you do

jmljunior on November 16, 2012

This is indeed a glaring issue.

A catalog page with 6 product nodes referencing product entities causes the cache_form table to grow about ~1.6MB on each page hit! This has brought down our site several times with large traffic.

We were truncating the table hourly, now every 15 minutes, looking into an approach that does not cache the forms on the product pages at all.

This really needs to be fixed by design.

enfreeco on November 20, 2012

I finally solved! My problem was due to the grid view that displayed products. I had hidden the field "Commerce product" and each product loaded the form ADD TO CART. In sites with many products (like mine) display the form in the view add to cart product search leads to an explosion in the table cache_form.

sorry for my bad English!

jmljunior on December 11, 2012

Still no word on this?
Why is my entire product node cached in cache_form, including the description, image URLs, etc.? Shouldn't it just cache the add to cart form?

sher1 on May 27, 2013

I don't know why it aggressively caches everything in cahce_form, but I am trying out this function in my template.php file
--My Theme is at_commerce

function at_commerce_cron() {
$result = db_truncate('cache_form')->execute();
watchdog('cache_form truncate', $result);

It should truncate the cache_form table and write the results to the watchdog on every cron run. Then at least you don't have to worry about manually clearing the table.

efitzg on June 19, 2013

My cache form table grew to over 3 GB before I found this issue. Caused a huge problem when pulling the DB from live back to development. If I hadn't been doing an upgrade who know how long it would have gone on before killing the server.

bojanz Bojan Zivanovic on August 6, 2013

You are posting a bug report to drupalcommerce.org (which is primarily for support), while the place for bug reports is the drupal.org issue queue. No Commerce developer ever saw this link.

The latest two Commerce releases include my fix which drastically decreased the size of the cache entry per node (from more than a mb, to a few hundred kb). So most of the complaints from 2012 are invalid.
There are probably other edge cases that can be optimized for (the latest posts). But that's for the issue queue.

EDIT: The last issue is actually a Views bug. See https://drupal.org/node/2057073#comment-7728457