Better Adjustments management

Definitely.

I'm developing an online bike shop where some of the products have 8 attributes. This causes a combinatorial explosion in the SQL query in pager_query() in uc_product_adjustments_form(). i.e.

SELECT COUNT(*) FROM (uc_product_options AS po1 LEFT JOIN uc_attribute_options AS ao1 ON po1.oid = ao1.oid AND po1.nid = 36), (uc_product_options AS po2 LEFT JOIN uc_attribute_options AS ao2 ON po2.oid = ao2.oid AND po2.nid = 36), (uc_product_options AS po3 LEFT JOIN uc_attribute_options AS ao3 ON po3.oid = ao3.oid AND po3.nid = 36), (uc_product_options AS po4 LEFT JOIN uc_attribute_options AS ao4 ON po4.oid = ao4.oid AND po4.nid = 36), (uc_product_options AS po5 LEFT JOIN uc_attribute_options AS ao5 ON po5.oid = ao5.oid AND po5.nid = 36), (uc_product_options AS po6 LEFT JOIN uc_attribute_options AS ao6 ON po6.oid = ao6.oid AND po6.nid = 36), (uc_product_options AS po7 LEFT JOIN uc_attribute_options AS ao7 ON po7.oid = ao7.oid AND po7.nid = 36), (uc_product_options AS po8 LEFT JOIN uc_attribute_options AS ao8 ON po8.oid = ao8.oid AND po8.nid = 36) WHERE ao1.aid = 6 AND ao2.aid = 7 AND ao3.aid = 9 AND ao4.aid = 10 AND ao5.aid = 15 AND ao6.aid = 16 AND ao7.aid = 17 AND ao8.aid = 22 |

This sends the corresponding mysql thread into 100% CPU usage, and this persists (effectively forever) even after apache has returned an "internal server error" page. In a shared hosting environment this is extremely undesirable. I think you could also make a case that this is a security issue - denial of service against the db server.

I ended up disabling adjustments altogether with...

function ffc_custom_menu_alter(&$items) {
$items['node/%node/edit/adjustments']['access callback'] = FALSE;
}

I've changed this issue's category from "feature request" to "bug report". Apologies if that's not the right way to report this.

I see my comment is basically a duplicate of
http://drupal.org/node/375019
Reverting to "feature request"

The combinatoric effect on the SQL query is the subject of #375019: Adjustments page breaks MySQL on too many attribute option combinations, so I'm moving this back to a feature request to add control the available combinations via a UI.

I'd love it if somebody reviewed my patch for http://drupal.org/node/375019 - it hopefully fixes the cratering of having too many attributes.

To be able to allow a user to exclude attributes from the adjustments table, we would need to add that option to the uc_attribute_options_form, and uc_object_options_form and additionally add one more column to each of the attribute option tables (uc_attribute_options, uc_class_options, uc_product_options) to specify whether or not this was an attribute that needs to be factored in for the adjustments.

Second, we would have to ensure that that column was queried on in the various locations that need it like:

uc_attribute_cart_item() - dont want to attach the whole 'combination' to the cart only the combination that is relevant to the SKU lookup (the attributes would still be defined, just the 'combination' would look different.
and
uc_product_adjustments_form() - remove any attributes from the potential list of adjustments that have no bearing on the SKU or Models.

New features should go into 7.x-3.x first.