Exception if target_path or request_path are exceeding 255 characters

[DanieliMi]

Describe the bug
When importing products with a (very) long category path and url key (together exceeding 255 characters) it will end up in an SQL exception since request_path and target_path in the url_rewrites table are VARCHAR(255).

To Reproduce
Steps to reproduce the behavior:

1. Import a product in a multi store setup with a very long category path and url key (this is an example csv) vendor/bin/import-simple import:create:ok-file && vendor/bin/import-simple import:products
2. Change the url_key of the de_de entry e.g. adding a number or replacing a character and import again vendor/bin/import-simple import:create:ok-file && vendor/bin/import-simple import:products
3. See the following error

ERROR: Can't finish import with serial 43cde188-a13b-47c8-afd6-e2acb4c164cd in 3.456523 s
 SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'request_path' at row 1 when executing SQL "INSERT
               INTO url_rewrite
                    (entity_type,
                     entity_id,
                     request_path,
                     target_path,
                     redirect_type,
                     store_id,
                     description,
                     is_autogenerated,
                     metadata)
             VALUES (product,
                     4633,
                     default-category/long-main-category-name/very-long-sub-category-name/even-longer-sub-category-name/DE-This-Is-Product-With-a-Ridiculously-Long-Product-Name-That-Exceeds-Any-Expectations-Of-Long-Product-Names-And-It-Includes-The-Product-SKU-24-MB01-12345678901.html,
                     catalog/product/view/id/4633/category/744,
                     0,
                     1,
                     ,
                     1,
                     {"category_id":"744"})" in file url-rewrite_20161021-161909_02.csv on line 2 

Expected behavior
To be decided. Maybe following Magento and cutting off the end?

Additional context
Tested with revision 381fd2e

[amenk]

@wagnert How shall we proceed with this? We can have a look at it if you confirm that we just should cut-off the URL key? Or do you think it's more complicated?

[wagnert]

@amenk Simply cutting it off may result in #22, so I think it can only be a temporary solution. We've to take care about this, when we make the URL keys unique like here. Give me one more day to think about it, a real solution will probably not too easy to implement.

[amenk]

I tried

in \TechDivision\Import\Utils\UrlKeyUtil::makeUnique

public function makeUnique(UrlKeyAwareSubjectInterface $subject, array $entity, string $urlKey, array $urlPaths = array()) : string
{

    $maxPathLength = 0;
    foreach($urlPaths as $path) {
        if ($maxPathLength < strlen($path)) {
            $maxPathLength = strlen($path);
        }
    }

  $maxLength = 255 - 5;
  $reservedForCounter = 10;
  $availableLength = $maxLength - $reservedForCounter - $maxPathLength;
  $urlKey = substr($urlKey, 0, $availableLength);

But in the second call to this function $urlPaths() is empty, so the resulting URL key does not get shortened there.

Not sure it that is to overengineered ... I mean at the end of the day, it depends on how deep the categories are nested in the catalog. It's not easy to solve.

We could as well just limit product URL keys to x characters, maybe using a setting.

[amenk]

We decided in our case to limit the product URL key to 40 letters, so the problem is avoided in most of the cases.
I believe solving this fully automatic and for all cases is not trivial.

Imaging you have super long category names which are combined already more than 255 letters -> there will be no space for the product name (and also not for the incremental numbers).

One approach could be to iteratively shorten the category names as well in such cases, but this is quite some algorithmic challenge and there might be no one-fits-all solution for this.

[wagnert]

@amenk We've that problem with one of our customers also, so we've to find generic solution for sure. But as you mentioned, it'll no be trivial. I'm happy to hear, that you've a temporary solution. I'll let the issue open and put it on the board during one of the next sprints. Thanks for supporting.