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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

TR created an issue. See original summary.

longwave’s picture

Status: Active » Needs review
FileSize
5.6 KB

Multiple fixes:

  • Set default values and proper settings for our base fields
  • Implement generateSampleValue() in our custom field items
  • Detect when devel_generate is being used and generate sample values
TR’s picture

The 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?

longwave’s picture

FileSize
5.6 KB
705 bytes

This 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?

longwave’s picture

Currently 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?

TR’s picture

I 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?

longwave’s picture

FileSize
952 bytes
6.07 KB

This 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.

TR’s picture

Status: Needs review » Reviewed & tested by the community

The patch in #7 works for me. I guess I could live with 40 character dummy SKUs, given the effort to override the default.

longwave’s picture

Status: Reviewed & tested by the community » Fixed

  • longwave committed 8abc0eb on 8.x-4.x
    Issue #2677224 by longwave: Make product entity work with devel generate
    
TR’s picture

Status: Needs review » Fixed

I don't know how this got set back to "Needs review" ... should be "Fixed".

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.