Как организовать временное хранение картинок?

Question

[Иван Антонов]

Здравствуйте.

Пользователи на сайт размещающие объявления, в которые можно вставлять картинки. Картинки загружаются и для каждой создается отдельная запись в БД. Но что, если пользователь передумает размещать объявление и просто закроет браузер, фотография останется и будет лежать на сервере ненужным грузом.

Подскажите разумный путь предотвращения появления неиспользуемых файлов.

Организация БД следующая
Все файлы у меня хранятся в таблице files.
А для картинок объявлений есть еще одна таблица offers_images с полями
offer_id - номер объявления в таблице offers
file_id - номер файла в таблице files

Comments

[LINKeR UA]

А вы не хотите отправлять файлы в месте с запросом на создание\редактирование объявления? Тогда и вопрос этот отпадет.

Answer 1

[Евгений Вольф]

Всё предельно просто.

Первое, что Вам понадобиться - это смириться с мыслью, что для подобных задач предназначен планироващик, например, CRON. Не всем это нравится, но... по факту без него довольно сложно обойтись. CRON есть на любом нормальном хостинге, не говоря уже про какие-то более полноценные варианты (VPS, Dedic. и т.д.)

У Вас есть картинки, которые привязаны (должны быть) к какому-то объявлению, которое создаётся ранее. С помощью CRON'а, вы находите объявления, которые более не ликвидны (недоопубликованы например) и по простой связи находите их картинки и удаляете всё сразу (и объявления и картинки).

Другой вариант: у Вас объявление создаётся позже, чем картинки. То есть, картинки некоторое время, до полного формирования объявления существуют в некоем вакууме. В этом случае, Вы добавляете каждой картинке поле - "дата загрузки" и выбираете все картинки, дата загрузки которых была более суток назад и которые не привязаны ни к одному объявлению (т.е. поле объявление_id == NULL).

Всё это делается по CRON'у, который запускает какой-то метод контроллера (судя по тому, что Вы используете Symfony). Обычно эту задачу решает утилита wget, которую запускает CRON. Что бы предотвратить "случайные" запуски со стороны пользователей - можно добавить проверку по GET-параметру, содержащему какой-нибудь хеш.

Comments

[Иван Антонов]

Эх, а я хотел обойтись без CRON, похоже не судьба :)
Второй вариант у меня уже реализован, но т.к. таблица с файлами используется везде на сайте, размер запроса возрастает.

SELECT f.`id`, f.`file`

FROM `files` f
LEFT JOIN `offers_images` oi 		ON oi.`image` = f.`id`
LEFT JOIN `companies` cn 		ON cn.`image` = f.`id`
LEFT JOIN `posts` p 				ON p.`image` = f.`id`
LEFT JOIN `complex` cx 				ON cx.`image` = f.`id`
LEFT JOIN `complex_declarations` cd ON cd.`file` = f.`id`
LEFT JOIN `complex_gallery` cg 		ON cg.`file` = f.`id`
LEFT JOIN `complex_plans` cp1 		ON cp1.`image` = f.`id`
LEFT JOIN `complex_plans` cp2 		ON cp2.`original_image` = f.`id`
LEFT JOIN `banners` b1 				ON b1.`project` = f.`id`
LEFT JOIN `banners` b2 				ON b2.`embed` = f.`id`
LEFT JOIN `banners` b3 				ON b3.`img` = f.`id`

WHERE
            oi.`id` IS NULL AND
            cn.`id` IS NULL AND
            p.`id` IS NULL AND
            cx.`id` IS NULL AND
            cd.`id` IS NULL AND
            cg.`id` IS NULL AND
            cp1.`id` IS NULL AND
            cp2.`id` IS NULL AND
            b1.`id` IS NULL AND
            b2.`id` IS NULL AND
            b3.`id` IS NULL AND 
            (f.`loaded_at` IS NULL OR f.`loaded_at` <= :loaded)

[Иван Антонов]

Тяжко однако на тостере с форматированием кода

[Евгений Вольф]

Иван Антонов: если это MySQL - результаты запрсов кэшируются, и проблем особо не будет. Если это PostgreSQL - можно создать "материализованное представление" или рассмотреть какой-то другой вариант. Или, можно использовать Memcache/Redis, для хранения данных и сокращения нагрузки на БД, но в целом, лаже в таком варианте запроса - особых проблем нет, это довольно небольшой запрос, в общей сложности и если скорость работы устраивает - то всё отлично.

Единственное, что бы я пожалуй, изменил по возможности - это сделал бы привязку файлов только тем сущностям, которым они реально нужны. Например, если картинка нужна для объявлений - то таблица картинок для объявлений; если картинка для аватарки - то таблица с картинками для аваторок и т.д. (если конечно одна и та же картинка не может использоваться много раз в разных местах, но тогда Вы либо не построите полноценную связь, либо наплодите кучу побочных таблиц).

[Иван Антонов]

Евгений Вольф: я как-то пытался избавиться от сущности File (таблица files) переносом всех картинок по целевым таблицам, но так как в File имеется логика по загрузке файлов (взятая из туториала Symfony) я бросил это дело.

[Евгений Вольф]

Иван Антонов: думаю, если Вас в целом устраивает полученный результат, то можно оставить "как есть". В ином случае (когда он Вас устраивать перестанет) - найдется и время и возможность всё поменять. Прелесть БД, в том, что можно практически безшовно делать изменения данных "наживую", практически без остановки боевого проекта :)

[Алексей Скобкин]

Всё это делается по CRON'у, который запускает какой-то метод контроллера

Ну что вы такое говорите-то. Какой контроллер. По CRON надо дёргать команды.

Иван Антонов

Эх, а я хотел обойтись без CRON, похоже не судьба :)

Нет, это как раз делают через CRON. На лету при загрузке страниц такими вещами не занимаются.

[Евгений Вольф]

> Ну что вы такое говорите-то. Какой контроллер. По CRON надо дёргать команды.
Я к сожалению, не так хорошо знаком с Symfony, возможно Вы правы на счёт и это лучшее решение, но... В некоторых фреймворках механизм команд полностью отсутствует, и они отлично справляются контроллером плюс к тому, не факт что на сервере есть доступ к PHP-CLI (если это не VPS/Dedic).

[Иван Антонов]

Евгений Вольф: Алексей Скобкин:
Ребят я использую Symfony Console Commands.
И задача в cron у меня выглядит примерно так:

/opt/php55/bin/php ~/www/site.ru/bin/console app:clear --not-used-files

[Евгений Вольф]

Иван Антонов: я думаю, Вам стоит задать отдельный вопрос относительно написания собственных симфони-команд, если с этим трудности. Но лично я не вижу в этом сокрального смысла (выносить это именно как команду), возможно от того, что я пока не симфони эксперт... но как мне видится, симфони-команда это что-то универсальное для симфони/фреймворка как такового, т.е. глобально, а не задач уровня "удалить N файлов в одном конкретном проекте". Хотя, свои преимущества в них безусловно есть, впрочем так же как и в любом другом подходе, например написать шелл-скрипт (или демон) который будет мониторить файловую систему на изменения с помощью соответствующего механизма ядра Linux (Inotofy), и через 10-30-N минут после появления файла в файловой системе, проверять, появился ли у этого файла владелец и если нет - удалять его, например с помощью специально написанной ранее консольной симфони-команды типа bin/console delete:file --id 75. А ещё будет супер, если этот демон будет написан на чистом Си... я думаю, Вы понимаете к чему это я. Каждый подход имеет свои преимущества и недостатки, вопрос исключительно в здравом смысле тех или иных решений :)

[Евгений Вольф]

Иван Антонов: хотя, если оно уже вынесено как команда и Вас устраивает - то почему бы и нет. Я не пытался сказать о том, что какой-то из способов не верный :)

[Алексей Скобкин]

Евгений Вольф: Контроллеры плохи тем, что они светятся наружу. А Symfony Console - это независимый компонент, его можно к любому фреймворку подключить очень просто.

[Евгений Вольф]

Алексей Скобкин: тут я с Вами согласен, что они "светятся наружу", но админ-панель с большей вероятность наружу светится... это не повод делать вместо админ-панели управление сайтом через консоль. Эту проблему решает банальное отсутствие вывода в браузер - проверка гет-параметра, если задан и задан правильно - выполняем действие N.

А если симфони-консоль полностью переносится на любой другой ФВ, я подозреваю, что в ней нет встроенных механизмов для работы с БД, а если так, то вместо готового контроллера настроенного именно под этот проект, с готовым конфигом и моделями/репозиторями и пр. механизмами для обслуживания БД - мы будем писать очередной велосипед, для обработки данных. К тому же, как я уже писал выше - эта команда будет нужна и будет работать только в этом конкретно взятом проекте, это же не composer-модуль для управления картинками, а код написанный в рамках (и исключительно для) этого проекта, который эти картинки загружает. По этому, вопрос переносимости - мало актуален для этого индивидуального случая. Если уж совсем глубоко копать, контроллеры тоже могут быть перенесены либо "как есть", либо с минимальными телодвижениями :)

[Алексей Скобкин]

Евгений Вольф:

тут я с Вами согласен, что они "светятся наружу", но админ-панель с большей вероятность наружу светится... это не повод делать вместо админ-панели управление сайтом через консоль.

Как-то не уловил суть сравнения админки с заданием для планировщика.

Эту проблему решает банальное отсутствие вывода в браузер - проверка гет-параметра, если задан и задан правильно - выполняем действие N.

"Эту проблему можно решить используя костыли". А можно и нормально.

А если симфони-консоль полностью переносится на любой другой ФВ, я подозреваю, что в ней нет встроенных механизмов для работы с БД, а если так, то вместо готового контроллера настроенного именно под этот проект, с готовым конфигом и моделями/репозиторями и пр. механизмами для обслуживания БД - мы будем писать очередной велосипед, для обработки данных.

Если у вас такая архитектура, что при добавлении универсального компонента для работы с БД в нём вам придётся писать велосипеды, то поздравляю, проект можно вообще целиком переписывать с нуля. Если у вас работа с БД жёстко завязана на контроллер, то это как-то странновато.

К тому же, как я уже писал выше - эта команда будет нужна и будет работать только в этом конкретно взятом проекте, это же не composer-модуль для управления картинками, а код написанный в рамках (и исключительно для) этого проекта, который эти картинки загружает. По этому, вопрос переносимости - мало актуален для этого индивидуального случая.

Не понял, что вы хотели этим сказать. Какой вопрос переносимости?

[Евгений Вольф]

>Как-то не уловил суть сравнения админки с заданием для планировщика.
Суть сравнения в том, что админка точно так же светится как и любой другой публичный контроллер, но это не мешает ей быть защищенной от постороннего вмешательства в её работу.

> Если у вас такая архитектура, что при добавлении универсального компонента для работы с БД в нём вам придётся писать велосипеды, то поздравляю, проект можно вообще целиком переписывать с нуля. Если у вас работа с БД жёстко завязана на контроллер, то это как-то странновато.
Консоль - это, насколько мне известно, универсальный компонент для работы с командной строкой, а не БД. И работа с БД "жестко отвязанная от контроллера" (как пример другой крайности) - по моему, ничуть не лучше, чем работа с БД жестко к контроллеру привязанная. А вообще я говорил о том, что в контроллере уже есть всё необходимое для работы с БД, особенно в Symfony. Не думаю, в универсальном и переносимом компоненте "консоль" из коробки и без лишних телодвижений, сразу же будут аналогичные возможности для работы с БД, какие есть в проекте на уровне контроллера этого проекта. Так же как до сих пор не думаю, что есть какой-то смысл переносить консольную команду заточенную исключительно под 1 проект - в какой-то другой проект, где она работать не будет (в виду разности архитектур БД). Или Вы предлагаете вместо просто удаления конкретного набора файлов в соответствии с парой простых правил в рамках проекта - написать целый универсальный комбайн со сложными схемами работы, для универсальности удаления нескольких файлов?

[Иван Антонов]

Алексей Скобкин: Евгений Вольф:
Что-то мы далеко ушли от темы :) и главный вопрос уже решен.
Евгений Вольф: Все верно, Symfony Console Commands есть обычный компонент для работы с консолью. Но что мешает Вам использовать другие модули в своей команде (такие как работа с БД). В случае же с самим фреймверком Symfony он просто расширяет класс настройки команды, добавляя контейнер в котором хранятся все используемые в проекте модули.
Не стоит пугаться того что вам неизвестно, почитайте, может заинтересует https://symfony.com/doc/current/console.html

[Иван Антонов]

Евгений Вольф: Команды настраиваются созданием отдельного класса, который никак не влияет на ядро компонента, поэтому один компонент можно использовать в нескольких проектах. Конечно если вы хотите перенести Symfony Console Commands на проект в котором нет нормального ООП, вам нужно будет задуматься о его интеграции. Console Commands в Symfony имеет полный функционал контроллера, так что нет смысла за это переживать.

[Алексей Скобкин]

Евгений Вольф:

Суть сравнения в том, что админка точно так же светится как и любой другой публичный контроллер, но это не мешает ей быть защищенной от постороннего вмешательства в её работу.

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

И работа с БД "жестко отвязанная от контроллера" (как пример другой крайности) - по моему, ничуть не лучше, чем работа с БД жестко к контроллеру привязанная.

Строго говоря, наоборот. Низкая связность компонентов - залог отсутствия лишней головной боли.

Так же как до сих пор не думаю, что есть какой-то смысл переносить консольную команду заточенную исключительно под 1 проект - в какой-то другой проект, где она работать не будет (в виду разности архитектур БД). Или Вы предлагаете вместо просто удаления конкретного набора файлов в соответствии с парой простых правил в рамках проекта - написать целый универсальный комбайн со сложными схемами работы, для универсальности удаления нескольких файлов?

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

[Евгений Вольф]

> Что-то мы далеко ушли от темы :) и главный вопрос уже решен.
Согласен! :)

> Но что мешает Вам использовать другие модули в своей команде (такие как работа с БД).
Отсутствие переносимости подобных решений и/или, не редко, - отсутствие в них смысла. Как я уже неоднократно писал выше, лично мне, наслаивание "других модулей" поверх некоторой команды мешает тот момент, что все эти модули в уже готовом и настроенном виде уже есть в контроллере (если говорить про данный конкретный пример). В остальном, как я уже писал выше - любое решение имеет право на жизнь, и если оператора не устраивает лежащий рядом (готовый и настроенный) молоток для забивания гвоздей и ему нравится для этих целей использовать дуршлаг с примотанным изолентой к нему кирпичом - это безусловно его право. В данной аллегории - дуршлаг - это универсальный интерфейс для разных задач, кирпич - это сторонние модули, которые нам ничего не мешает использовать (ну кроме здарвого смысла, разумеется). Молоток - олицетворяет уже готовый и настроенный контроллер, к которому уже априори прикручено и настроено всё, что может понадобиться для решения конкретно этой, узкоспециализированной и плохо переносимой (в другие проекты) задачи, для конкретно этого проекта :)

[Евгений Вольф]

> Вы по-прежнему не сказали, зачем светить внутренние механизмы приложения наружу. То, что можно нагородить на них костыли защиты - это понятно и без объяснений.
Не понимаю, в Вашей интерпретации означает "светить"? Как некий "злоумышленник" догадается, что существует некий адрес (внутренний механизм), вроде: http://site.com/ClearImageShit/?secretkey=длинный_ключ ? Откуда бы этот внутренний механизм внезапно "засветился"?

> Строго говоря, наоборот. Низкая связность компонентов - залог отсутствия лишней головной боли.
Низкая связанность компонентов - работает в том случае, когда мы пишем некоторый универсальный код. А когда речь идёт о вполне конкретной структуре БД, с вполне конкретной архитектурой, заточенной строго под данный конкретный проект - то связанность самих компонентов тут не играет никакой роли вообще. От того, что готовая команда будет запускаться на другом проекте и делать в лучшем случае "ничего" (полезного), т.к. там абсолютно другая архитектура БД - толку примерно никакого, и слабая связанность компонентов осмысленности подобным решениям не добавляет.

[Евгений Вольф]

> Вы по-прежнему не сказали, зачем светить внутренние механизмы приложения наружу. То, что можно нагородить на них костыли защиты - это понятно и без объяснений.
Насколько мне известно, например, панель управления сайтом - это то, что можно отнести к разряжу "внутренние механизмы". Правильно ли я понимаю, что наличие оной - есть плохой тон, т.к. в 99.9% случаев, она "светится наружу", а система авторизации пользователей (для входа в эту панель) - есть "костыль в виде защиты"?

[Иван Антонов]

Евгений Вольф: но ведь даже в проект "с вполне конкретной архитектурой" частенько требуются обновления и если вдруг вам потребуется для каких-то целей консольная команда, Вы станете ее заново изобретать или возьмете уже готовое решение?

[Иван Антонов]

Евгений Вольф: Как я понял из разговора, внутренний механизм - это задачи решаемые на сервере без участия пользователя. А админка делается всё-таки для пользователей, хоть и более привилегированных. В ином случае весь сайт можно назвать внутреннем механизмом.

[Иван Антонов]

Евгений Вольф:

От того, что готовая команда будет запускаться на другом проекте и делать в лучшем случае "ничего" (полезного), т.к. там абсолютно другая архитектура БД - толку примерно никакого, и слабая связанность компонентов осмысленности подобным решениям не добавляет.

Вы команду готовите сами, Symfony Console Commands предоставляет только методы для работы с консолью. И шла речь о переносимости компонента Symfony Console Commands, а не исполняемой команды.

[Евгений Вольф]

> И шла речь о переносимости компонента Symfony Console Commands, а не исполняемой команды.
Да, но какой смысл переносить консоль без самой команды? Мы же тут конкретный проект обсуждали, и конкретный случай, вопрос о переносимости самой консоли вне рамок текущего проекта и конкретной задачи не стоял изначально.

[Иван Антонов]

Евгений Вольф:

Мы же тут конкретный проект обсуждали, и конкретный случай, вопрос о переносимости самой консоли вне рамок текущего проекта и конкретной задачи не стоял изначально.

Это вы обсуждали, а мы не можем понять что вы хотите сказать, только по последним приложениям стало ясно, что мы говорим совсем о разных вещах.
Рекомендую перечитать все сообщения с самого начала :) вы походу сами уже запутались. О переносимости команд (логики одного приложения в другое) не может быть и речи! Шла речь о переносимости этого компонента на те фреймворки в которых "механизм команд полностью отсутствует".

[Иван Антонов]

Евгений Вольф:

А если симфони-консоль полностью переносится на любой другой ФВ, я подозреваю, что в ней нет встроенных механизмов для работы с БД, а если так, то вместо готового контроллера настроенного именно под этот проект, с готовым конфигом и моделями/репозиторями и пр. механизмами для обслуживания БД - мы будем писать очередной велосипед, для обработки данных.

Просто наследуете класс от контроллера и имеете все необходимые механизмы.

[Евгений Вольф]

> Просто наследуете класс от контроллера и имеете все необходимые механизмы.
В разных ФВ - разные контроллеры и разные механизмы.

> Это вы обсуждали, а мы не можем понять что вы хотите сказать, только по последним приложениям стало ясно, что мы говорим совсем о разных вещах.
Речь шла о том, что решение с контроллером имеет полное право на жизнь, точно такое же, как и любое другое решение. После чего, я "услышал" ряд довольно абсурдных аргументов о том, что решение на уровне консоли "лучше", т.к. консоль - это переносимый компонент (в данном случае - переносимый никуда), а банальная авторизация (проверка прав и/или условий, хотя бы самая примитивная) которая используется чуть мене чем везде - это "костыль"...

Ещё можно было бы обсудить shell/python-скрипты, т.к. в отличии от PHP они есть в 99/90% систем соответственно, и они ещё более переносимы :D

Answer 2

[Андрей]

Я бы добавил ещё 2 поля в таблицу:
- флаг использования в объявлении (tinyint);
- дата загрузки (timestamp).
По умолчанию при загрузке картинки значение флага равно нулю. Когда пользователь разместит объявление - единице.
Далее раз в сутки (ночью, наверное) скрипт ищет в БД все записи с флагом = 0 и датой создания более суток. Всё что найдёт - удаляет (как записи в БД, так и файлы).