Closed (fixed)
Project:
Commerce Core
Version:
8.x-2.x-dev
Component:
Order
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
3 Jul 2012 at 12:23 UTC
Updated:
10 Oct 2015 at 11:24 UTC
Jump to comment: Most recent
I will add more details to this report later, but long story short: after having inserted a few thousand orders, the database dump was something like 200M. Biggest tables (making the other tables sizes insignificant) where field tables, most importantly the commerce_line_items field one (both data and revision). This was due to order revisioning: a simple scenario, add 2 products to cart then checkout in 2 pages gave an average of 8 revisions per order, thus making the line items reference field table growing with a factor (8 * average number of line items per order).
One simple way of avoid that would be to force orders with cart statuses not to be revisionned at all. Anyway, it seems quite useless to me to allow cart revisions, carts are highly mutable and their revisions will bloat the database without any purpose. If I'm wrong please tell me, but in my current use case this probably will cause scalability problems soon enough.
Comments
Comment #1
rszrama commentedWe intentionally made order revisioning the default for all carts to be able to capture in the order history the changes that occur on an order prior to conversion. This data would allow a site to understand how long it took a customer to get from adding a product to the cart to checking out and what steps occurred along the way. I agree that this isn't essential data for every site (or most sites), though, and it seems like something we can reevaluate for 2.x - especially since there are analytics services like Jirafe that may better track, analyze, and visualize the appropriate data points.
That said, you can still force orde rrevisioning off by default from the order settings form - but that won't work for just cart orders. I'd be open to extending that form to allow you to target just cart orders. In the meantime, you can just implement hook_commerce_order_presave() and unset $order->revision for cart orders yourself.
Moving this to a task and putting it on the 2.x issue list as behavior to reconsider for the next version.
See: #1467180: Open 2.x Drupal Commerce branch
Comment #2
pounardOk, thanks for the details.
Comment #3
pounardI just wanted to say that the trick on presave did the job, I just unconditionnally disabled order revisioning, and it saved my life (or more the life of my database server), thanks a lot.
Comment #4
rszrama commentedOk, glad to hear it. This should definitely be revisited as it's a sort of power feature that probably isn't utilized by many of our users but affects them all (similar to the product sell price pre-calculation feature that forces all price manipulation through Rules).
Comment #5
rszrama commentedLooks like we just need to reevaluate this for 2.x. My hunch is we've already taken care of it, just haven't read closely.
Comment #6
bojanz commentedWe gave up on order revisioning completely :) I guess that counts as solved.
To clarify, revisioning in Drupal core can't cover multiple entities at the same time. So revisioning orders while line items, customer profiles and payments stay unrevisioned ends up not being useful. The data is also very hard to consume. Both Ryan and myself agreed that for any kind of analysis it makes more sense to fill a custom table with the relevant data, or use an external service.