С учётом примерно полного отсутствия (кроме того, что у Вас 1500 записей которые надо достать из базы неведомого размера, работающей на неведомом железе и поиском по непонятным условиям, с непонятным количеством индексом и всем вообще остальным) информации - Вам мало кто подскажет что-то толковое. С вероятностью 95% Вы получите ответ ровной такой же, как и сам вопрос.
> Просто наследуете класс от контроллера и имеете все необходимые механизмы.
В разных ФВ - разные контроллеры и разные механизмы.
> Это вы обсуждали, а мы не можем понять что вы хотите сказать, только по последним приложениям стало ясно, что мы говорим совсем о разных вещах.
Речь шла о том, что решение с контроллером имеет полное право на жизнь, точно такое же, как и любое другое решение. После чего, я "услышал" ряд довольно абсурдных аргументов о том, что решение на уровне консоли "лучше", т.к. консоль - это переносимый компонент (в данном случае - переносимый никуда), а банальная авторизация (проверка прав и/или условий, хотя бы самая примитивная) которая используется чуть мене чем везде - это "костыль"...
Ещё можно было бы обсудить shell/python-скрипты, т.к. в отличии от PHP они есть в 99/90% систем соответственно, и они ещё более переносимы :D
> И шла речь о переносимости компонента Symfony Console Commands, а не исполняемой команды.
Да, но какой смысл переносить консоль без самой команды? Мы же тут конкретный проект обсуждали, и конкретный случай, вопрос о переносимости самой консоли вне рамок текущего проекта и конкретной задачи не стоял изначально.
Не совсем понятно, что именно Вы хотите организовать. Если Вам нужен централизованный сервер хранения общих объектов, так вот на вскидку приходит мысль - берёте сервер PostgreSQL (центаральный), создаёте там все нужные инстансы, подключаете с удаленных серверов этот сервер, наследуете таблицы инстансов с центрального сервера на каждом клиенте и кастомизируете их там (на клиентах) как хотите.
> Вы по-прежнему не сказали, зачем светить внутренние механизмы приложения наружу. То, что можно нагородить на них костыли защиты - это понятно и без объяснений.
Насколько мне известно, например, панель управления сайтом - это то, что можно отнести к разряжу "внутренние механизмы". Правильно ли я понимаю, что наличие оной - есть плохой тон, т.к. в 99.9% случаев, она "светится наружу", а система авторизации пользователей (для входа в эту панель) - есть "костыль в виде защиты"?
> Вы по-прежнему не сказали, зачем светить внутренние механизмы приложения наружу. То, что можно нагородить на них костыли защиты - это понятно и без объяснений.
Не понимаю, в Вашей интерпретации означает "светить"? Как некий "злоумышленник" догадается, что существует некий адрес (внутренний механизм), вроде: http://site.com/ClearImageShit/?secretkey=длинный_ключ ? Откуда бы этот внутренний механизм внезапно "засветился"?
> Строго говоря, наоборот. Низкая связность компонентов - залог отсутствия лишней головной боли.
Низкая связанность компонентов - работает в том случае, когда мы пишем некоторый универсальный код. А когда речь идёт о вполне конкретной структуре БД, с вполне конкретной архитектурой, заточенной строго под данный конкретный проект - то связанность самих компонентов тут не играет никакой роли вообще. От того, что готовая команда будет запускаться на другом проекте и делать в лучшем случае "ничего" (полезного), т.к. там абсолютно другая архитектура БД - толку примерно никакого, и слабая связанность компонентов осмысленности подобным решениям не добавляет.
> Что-то мы далеко ушли от темы :) и главный вопрос уже решен.
Согласен! :)
> Но что мешает Вам использовать другие модули в своей команде (такие как работа с БД).
Отсутствие переносимости подобных решений и/или, не редко, - отсутствие в них смысла. Как я уже неоднократно писал выше, лично мне, наслаивание "других модулей" поверх некоторой команды мешает тот момент, что все эти модули в уже готовом и настроенном виде уже есть в контроллере (если говорить про данный конкретный пример). В остальном, как я уже писал выше - любое решение имеет право на жизнь, и если оператора не устраивает лежащий рядом (готовый и настроенный) молоток для забивания гвоздей и ему нравится для этих целей использовать дуршлаг с примотанным изолентой к нему кирпичом - это безусловно его право. В данной аллегории - дуршлаг - это универсальный интерфейс для разных задач, кирпич - это сторонние модули, которые нам ничего не мешает использовать (ну кроме здарвого смысла, разумеется). Молоток - олицетворяет уже готовый и настроенный контроллер, к которому уже априори прикручено и настроено всё, что может понадобиться для решения конкретно этой, узкоспециализированной и плохо переносимой (в другие проекты) задачи, для конкретно этого проекта :)
dev400: ну если букву "т" (вторую по счёту, в первом слове) из заголовка вопроса удалить, то глядя на код - вариант "без буквы т" будет лучше описывать всю эту боль :D
>Как-то не уловил суть сравнения админки с заданием для планировщика.
Суть сравнения в том, что админка точно так же светится как и любой другой публичный контроллер, но это не мешает ей быть защищенной от постороннего вмешательства в её работу.
> Если у вас такая архитектура, что при добавлении универсального компонента для работы с БД в нём вам придётся писать велосипеды, то поздравляю, проект можно вообще целиком переписывать с нуля. Если у вас работа с БД жёстко завязана на контроллер, то это как-то странновато.
Консоль - это, насколько мне известно, универсальный компонент для работы с командной строкой, а не БД. И работа с БД "жестко отвязанная от контроллера" (как пример другой крайности) - по моему, ничуть не лучше, чем работа с БД жестко к контроллеру привязанная. А вообще я говорил о том, что в контроллере уже есть всё необходимое для работы с БД, особенно в Symfony. Не думаю, в универсальном и переносимом компоненте "консоль" из коробки и без лишних телодвижений, сразу же будут аналогичные возможности для работы с БД, какие есть в проекте на уровне контроллера этого проекта. Так же как до сих пор не думаю, что есть какой-то смысл переносить консольную команду заточенную исключительно под 1 проект - в какой-то другой проект, где она работать не будет (в виду разности архитектур БД). Или Вы предлагаете вместо просто удаления конкретного набора файлов в соответствии с парой простых правил в рамках проекта - написать целый универсальный комбайн со сложными схемами работы, для универсальности удаления нескольких файлов?
Алексей Скобкин: тут я с Вами согласен, что они "светятся наружу", но админ-панель с большей вероятность наружу светится... это не повод делать вместо админ-панели управление сайтом через консоль. Эту проблему решает банальное отсутствие вывода в браузер - проверка гет-параметра, если задан и задан правильно - выполняем действие N.
А если симфони-консоль полностью переносится на любой другой ФВ, я подозреваю, что в ней нет встроенных механизмов для работы с БД, а если так, то вместо готового контроллера настроенного именно под этот проект, с готовым конфигом и моделями/репозиторями и пр. механизмами для обслуживания БД - мы будем писать очередной велосипед, для обработки данных. К тому же, как я уже писал выше - эта команда будет нужна и будет работать только в этом конкретно взятом проекте, это же не composer-модуль для управления картинками, а код написанный в рамках (и исключительно для) этого проекта, который эти картинки загружает. По этому, вопрос переносимости - мало актуален для этого индивидуального случая. Если уж совсем глубоко копать, контроллеры тоже могут быть перенесены либо "как есть", либо с минимальными телодвижениями :)
Иван Антонов: хотя, если оно уже вынесено как команда и Вас устраивает - то почему бы и нет. Я не пытался сказать о том, что какой-то из способов не верный :)
Иван Антонов: я думаю, Вам стоит задать отдельный вопрос относительно написания собственных симфони-команд, если с этим трудности. Но лично я не вижу в этом сокрального смысла (выносить это именно как команду), возможно от того, что я пока не симфони эксперт... но как мне видится, симфони-команда это что-то универсальное для симфони/фреймворка как такового, т.е. глобально, а не задач уровня "удалить N файлов в одном конкретном проекте". Хотя, свои преимущества в них безусловно есть, впрочем так же как и в любом другом подходе, например написать шелл-скрипт (или демон) который будет мониторить файловую систему на изменения с помощью соответствующего механизма ядра Linux (Inotofy), и через 10-30-N минут после появления файла в файловой системе, проверять, появился ли у этого файла владелец и если нет - удалять его, например с помощью специально написанной ранее консольной симфони-команды типа bin/console delete:file --id 75. А ещё будет супер, если этот демон будет написан на чистом Си... я думаю, Вы понимаете к чему это я. Каждый подход имеет свои преимущества и недостатки, вопрос исключительно в здравом смысле тех или иных решений :)
