Data too long for column 'model' when creating kit with many products

The model (SKU) of the product kit is automatically set to be a concatenation of the individual product models for the products in the kit. In your case, the resulting model exceeds 256 characters (the maximum allowed length of a model), which is why you see an error.

I suppose we should find a better way of automatically generating a product kit model. Just truncating it at 256 isn't sufficient because that might lead to multiple kits with the same model. Changing the size of this database field is the wrong thing to do, that just moves the point where the error occurs, and 256 is already quite large enough to hold single product models. A hash could be used; those typically aren't very "readable", however this may be the best way to go about it. Maybe the kit model should be this string "KIT" with a 32 character hash code appended?

If you're willing to ignore the error, which should appear only when you create the product kit, then everything from then on should work correctly. The product kit model number gets truncated, which is not ideal, but will work.

Let's leave this open until we have a fix that eliminates the error.

We could just add an SKU field for kits, so the user can specify one. Not sure if or how kits work together with stock tracking, we could perhaps make the SKU field optional if kits don't really need SKUs at all - surely the individual products in the kit should be the stock-keeping units.

I have a site that's being affected by this issue as well.

I feel like using a hash for the model makes sense, or maybe making the model optional so kits don't need it, since stock would be tracked on the individual products that make up the kit. Either that, or expose the SKU on node edit forms so we can set one that won't run up against this error.

All right, for my purposes, a simple solution of hard-coding the SKUs to "kit+nid" is good enough. In case that ends up being useful, here's a patch.

Unbelievable something like this was not fixed since then, it's very likely that product kits is the least used feature in ubercart :), although I used it a bit and this issue has just showed up in one of our clients.

Attached is a patch that does pretty much what @longwave suggested in #8, however, I didn't made SKU optional as that assumption could possible do more harm in how ubercart works internally. Instead I am simply making SKU required as per a normal product. It's really the most sensible fix for something like this, and won't change current product kits models.

Fixing tests, I think the taxonomy ones are unrelated to this issue.

ok, only this taxonomy test failing which is likely a work in progress of some other issue.

The test failure was due to a disruptive Drupal core commit that broke the test. I fixed the test in #2746103: D7.50 change breaks test.

Ubercart 8.x

CLI postgre db fix: "alter table uc_products alter model type varchar(255);" resolved the issue for me.
I would assume a mysql db would resolve in a similar way.

Is there anyone working on getting the additional field length put into the next Ubercart update?

@1computerninja: Please read the issue. Increasing the length of the model field is NOT a solution here, and this issue has nothing to do with whether you use PostgreSQL or MySql. In fact, in 7.x-3.x the model length WAS 255, and yet we still had this issue. In 8.x-4.x the length was deliberately reduced to 40 characters, which exacerbates this issue but doesn't affect the possible solution which was suggested by @longwave in #8 with a patch provided by @hanoii in #17. To help, you can test the patch from #17 for 7.x-3.x, or port that patch to 8.x-4.x and post it here for consideration.