Generate preview for images

[php-coder]

@Shkarin @Shagbark please, review this code and don't hesitate to ask any questions.

TBD:

• extract some unrelated changes to separate commits
• /tmp/upload -> /tmp/uploads
• squash commits
• update changelog
• move preview creation to the controller
• extract createPreview method
• add unique index to images_data table
• test that exception contains image id
• test adding series and adding additional image with files
• test when the feature is disabled
• show a time took for image preview generation

Addressed to #387

[php-coder]

Качество и размеры изображения выбраны практически наугад. Позже можно будет их изменить.

[mystamps-bot]

1 Error

🚫

maven-failsafe-plugin error in src/test/java/ru/mystamps/web/tests/cases/WhenUserAddSeries.java: Test case WhenUserAddSeries.shouldCreateSeriesWithAllFieldsFilled fails with error: The element seems to be disconnected from the DOM. This means that a user cannot interact with it. For documentation on this error, please visit: http://seleniumhq.org/exceptions/stale_element_reference.html Build info: version: ‘2.53.1’, revision: ‘a36b8b1cd5757287168e54b817830adce9b0158d’, time: ‘2016-06-30 19:26:09’ System info: host: ‘testing-gce-6c7c3484-0ece-4597-8a60-21d1be1e9619.c.travis-ci-prod-2.internal’, ip: ‘10.10.20.31’, os.name: ‘Linux’, os.arch: ‘amd64’, os.version: ‘3.13.0-115-generic’, java.version: ‘1.8.0_121’ Driver info: driver.version: HtmlUnitDriver

	1 Message
📖	maven-failsafe-plugin reported about 1 error. Please, fix it. See also: https://github.com/php-coder/mystamps/wiki/integration-tests

Generated by 🚫 Danger

[coveralls]

Coverage decreased (-3.4%) to 77.764% when pulling 60e57d4 on gh387_image_preview into 692e6f6 on master.

[php-coder]

Хочу с вами обсудить, как минимум, следующие вопросы:

1. сейчас при сабмите изображения мы в блокирующем режиме его сохраняем и делаем превью. Это может быть довольно долгий процесс, особенно теперь когда еще и превью создается, которое может есть память.
   Я думал в сторону чего-то асинхронного, но решил сначала сделать нечто работающее и потом улучшать. Но все-таки обсудить этот подход нам никто не мешает уже сейчас :) Ах, да, с асинхронностью будет еще такая проблема, что мы потеряем возможность быть в одной транзакции и почистить все за собой в случае исключения.

2. хотелось бы иметь возможность как-то перегенеривовать превью. Например, если я изменю исходное изображение или если мы решим изменить размер этих превью. Как бы вы это реализовывали?

3. в текущем подходе, мы возвращаем оригинальное изображение, если превью не существует. Возможно, что стоит попытаться это превью создать? Это, кстати, как раз случай для существующих на проде изображений, у которых превью нет и их нужно как-то создать.

[php-coder]

Я нашел подход, который поможет со всеми этими вопросами: превью нужно создавать не сразу же вместе с серией и изобржением, а позже, при первом запросе превью. Это решит вопрос создания превью для уже существующих изображений; создание серии будет более быстрым и менее подверженым ошибкам; кроме того не придется дублировать код для создания превью в двух местах (при создании серии и добавлении дополнительного изображения).

[coveralls]

Coverage decreased (-3.4%) to 77.764% when pulling 8ccfb89 on gh387_image_preview into 94fa3b7 on master.

[AleksSPb]

Я бы предложил в таблицу со ссылками на изображения, добавить поле preview_ready. При подгрузке новых изображений по умолчанию устанавливать значение false.
Сделать отдельный процесс, который будет выбирать из таблицы записи у которых не готово превью и генерировать их. После генерации заменяя значение поля preview_ready на true. Послеобработки процесс засыпает на какое-то время. Время сна может меняться в зависимости от количества ожидающих обработки изображений. Количество обрабатываемых за раз изображений должно настраиваться.
В случае если требуется отсутствующая превьюшка, она генерируется на лету.

[php-coder]

@AleksSPb Спасибо, что присоединился!

Я думал о такой возможности, но она а) добавляет много кода б) ничего не улучшает. Попробую обьяснить последний пункт: после создания серии пользователь перенаправляется на страницу с информацией об этой серии. На ней есть изображение и таким образом при открытии страницы превью либо уже должно быть, либо оно должно быть сгенерировано.

Т.е. запускать фоновый процесс не имеет смысла, так сразу же после добавления изображения мы должны сделать превью и вернуть его. Фоновый процесс может либо не успеть, либо, что хуже, начать делать превью одновременно с запросом, который генерирует превью на лету.

[php-coder]

Я бы предложил в таблицу со ссылками на изображения, добавить поле preview_ready.

P.S. Идея хорошая, но какую проблему мы этим решим? В текущем подходе мы можем определить есть превью или нет путем либо проверки существования файла (на проде), либо поиском в таблице image_content (встроенная БД). Т.е. этот механизм и есть замена полю preview_ready, только поле статичное, а проверка динамическая. В случае с полем, также появится шанс, что файла на файловой системе нет, а preview_ready установлена в true. Короче, чем больше флагов, тем сложнее состояние и больше шансов внести ошибку.

Если сейчас мне понадобится пересобрать превью на проде, то я должен буду просто удалить изображение в каталоге. Если у нас будет флаг, то кроме удаления изображения, мне придется также выпольнить SQL-запрос для обновления этого поля.

Я бы даже приделал это поле, если бы оно решало, что-то что не решается в текущем подходе.

[AleksSPb]

В такой постановке - лучше твоего решения не найти! 👍

[coveralls]

Changes Unknown when pulling 30d8478 on gh387_image_preview into ** on master**.

[coveralls]

Changes Unknown when pulling d484da4 on gh387_image_preview into ** on master**.

[coveralls]

Changes Unknown when pulling 6fd957e on gh387_image_preview into ** on master**.

[php-coder]

Merged in 5937d16 commit.