Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
As we approach beta, I find this increasingly important - it's hard to develop and test some things (e.g. catalog, reports, etc.) without content present, and it's a pain to manually generate enough content to be useful for testing these things.
When running Devel generate, I get these fatal errors:
Drupal\Core\Database\IntegrityConstraintViolationException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'model' cannot be null: INSERT INTO {uc_products} (vid, nid, model, cost, price, weight, weight_units, length, width, height, length_units, pkg_qty, default_qty, shippable) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10, :db_insert_placeholder_11, :db_insert_placeholder_12, :db_insert_placeholder_13); Array ( [:db_insert_placeholder_0] => 3 [:db_insert_placeholder_1] => 3 [:db_insert_placeholder_2] => [:db_insert_placeholder_3] => 0.00 [:db_insert_placeholder_4] => 0.00 [:db_insert_placeholder_5] => [:db_insert_placeholder_6] => [:db_insert_placeholder_7] => [:db_insert_placeholder_8] => [:db_insert_placeholder_9] => [:db_insert_placeholder_10] => [:db_insert_placeholder_11] => 1 [:db_insert_placeholder_12] => 1 [:db_insert_placeholder_13] => 1 ) in Drupal\Core\Database\Connection->handleQueryException() (line 673 of /home/d0rha/www/core/lib/Drupal/Core/Database/Connection.php).
Drupal\Core\Entity\EntityStorageException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'model' cannot be null: INSERT INTO {uc_products} (vid, nid, model, cost, price, weight, weight_units, length, width, height, length_units, pkg_qty, default_qty, shippable) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10, :db_insert_placeholder_11, :db_insert_placeholder_12, :db_insert_placeholder_13); Array ( [:db_insert_placeholder_0] => 3 [:db_insert_placeholder_1] => 3 [:db_insert_placeholder_2] => [:db_insert_placeholder_3] => 0.00 [:db_insert_placeholder_4] => 0.00 [:db_insert_placeholder_5] => [:db_insert_placeholder_6] => [:db_insert_placeholder_7] => [:db_insert_placeholder_8] => [:db_insert_placeholder_9] => [:db_insert_placeholder_10] => [:db_insert_placeholder_11] => 1 [:db_insert_placeholder_12] => 1 [:db_insert_placeholder_13] => 1 ) in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 757 of /home/d0rha/www/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).
Perhaps related to #2355731: EntityFieldQuery on uc_product node types not working.
It's unclear to me what exactly Devel requires from a content type in order to be able to generate nodes of that type.
Comment | File | Size | Author |
---|---|---|---|
#4 | interdiff-2677224.txt | 705 bytes | longwave |
#4 | devel-generate.patch | 5.6 KB | longwave |
|
Comments
Comment #2
longwaveMultiple fixes:
Comment #3
TR CreditAttribution: TR commentedThe patch works well, except that some of the generated values are ridiculously large. The long length of these values may break a layout and makes it difficult to visualize whether the layout will look good with more realistic numbers.
SKUs for example look to be several hundred random characters. I think 10 is more appropriate. Prices look more like real-estate prices - an average of five hundred thousands dollars per product. Maybe use a precision of 6 instead of 8?
Comment #4
longwaveThis patch reduces the sample price precision to 6.
Reducing the SKU is more complicated, as the sample values are generated by StringItem::generateSampleValues(), which can generate anything up to the maximum length of the SKU field. So, perhaps we should just reduce the SKU field length?
Comment #5
longwaveCurrently we allow 255 characters which is really too long. Amazon has a maximum SKU length of 40, perhaps we could reduce it to that? Or is 64 a better compromise?
Comment #6
TR CreditAttribution: TR commentedI didn't look at Amazon, I was thinking more in terms of UPC and EAN numbers, which are 12 digits and 13 digits respectively. Allowing characters in addition to digits greatly increases the number of combinations, but many SKU schemes are not designed for efficient use of the available characters, they're designed more for readability (e.g. a readable SKU might use RED for a color instead of R) so they tend to be longer.
Amazon ASIN numbers are 10 characters. I do see that if you want to sell your own product that's not in Amazon's catalog, you're allowed to specify your own SKU up to 40 characters, but that's not what Amazon uses internally.
Wal Mart, the world's largest retailer, uses 9 digit SKUs.
So there are two issues:
1) How big to make the SKU field. I was thinking that 16 characters is big enough but probably too restrictive if we consider readability. 32 is more reasonable. I'm not sure we have to go larger, but if you do want to cover the Amazon 40 characters case then we might as well change it to just 40 and no larger - any real storage is going to use 4 byte or 8 byte words, so 40 characters is an even number of words, no need to round to the nearest power of 2. (I don't know how databases handle UTF-8 storage internally, since that varies from 1-6 bytes per character, but regardless we don't have any control over that.)
2) How big a number to generate for test products. 40 characters is still anomalously large for a SKU, which is why I'd rather see us generate shorter strings of around 10 characters for testing, regardless of how big a string the SKU field can hold. How are things like machine_name and id generated - those don't seem to be made exceptionally long?
Comment #7
longwaveThis patch reduces SKU to 40 characters. generateSampleValue() will generate random SKUs between 1 and 40 characters. I don't think it is possible to alter this without subclassing StringItem and making our own SKU field, which seems unnecessary if the only reason is to generate slightly more realistic dummy SKUs.
Comment #8
TR CreditAttribution: TR commentedThe patch in #7 works for me. I guess I could live with 40 character dummy SKUs, given the effort to override the default.
Comment #9
longwaveComment #11
TR CreditAttribution: TR commentedI don't know how this got set back to "Needs review" ... should be "Fixed".