Удаление SQL записей

Чем аргументирует костыльность варианта с кроном?

Обычно в приложении для таких вещей проектируются хуки. На эти хуки потом такие вещи и вешаются.

Триггер на табличку с юзерами.

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

Как вариант, http://dev.mysql.com/doc/refman/5.1/en/create-event.html

Перед выборкой и удалять.

Увы, собственными предрассудками =)

Насколько я знаком с хуками... В данном случае сложнее хук написать, чем написать все остальное приложение =)

Спасибо.

Спасибо! Не знал о таком даже.

Тогда пусть страдает.

тогда нам нечем ему помочь

Хук это фигня какая то. Правильно использовать аналог крона в вашем проекте. Как вариант, чтобы не сильно заморачиваться - сделать какую-нибудь страничку типа /cronjobs.php и её дёргать реальным кроном (через wget), а в ней прописать логику.

Мне тут гуру подсказали отличное подобие очереди с либой для ПХП, зовётся сие чудо beanstalk, пхпшная либа - pheanstalk. Кидаешь задания на 30+ минут в очередь, воркер проверяет, если юзер не активировался - нафиг

Хук — это способ встраивания сторонних модулей в логику приложения. Поскольку автор топика говорил именно о доработке, то мне пришла мысль именно о хуках. А пони — это фигня, да.

Вариант: использовать хранимые процедуры СУБД.

Мне тут гуру подсказали отличное подобие очереди с либой для ПХП, зовётся сие чудо beanstalk, пхпшная либа - pheanstalk.

Тащем-то в PHP не только клиент к beanstalk есть, но и ActiveMQ, ZeroMQ, Celery, Gearman и т.п.

Удалять, чтобы не показывать? Это лучше делать один раз, ночью. А в течении дня, просто не выводить таких.

Тащем-то в PHP не только клиент к beanstalk есть, но и ActiveMQ, ZeroMQ, Celery, Gearman и т.п

Тогда уж лучше RabbitMQ.

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

Тут вопрос именно в автоматизации процедуры.

Спасибо за помощь, вариант с create event понравился.

её дёргать реальным кроном (через wget)

Зачем нагружать этим говном веб-сервер? Трудно через cli, чтоли, не понимаю.

Хук это фигня какая то. Правильно использовать аналог крона в вашем проекте. Как вариант, чтобы не сильно заморачиваться - сделать какую-нибудь страничку типа /cronjobs.php и её дёргать реальным кроном (через wget), а в ней прописать логику.

Буэ! Все нормальные фреймворки умеют CLI. [1] [2]

Например в веб-приложении могут быть объекты, дао и нужная задача реализуется гораздо проще, чем писать скрипты заново. Если cli, надо или дублировать функционал или делать всякие общие библиотеки. Опять же надо про права не забывать, пользователей нужных. Куча проблем на ровном месте.

А нагружается не веб-сервер, а база, причем в обоих случаях одинаково.

Если cli, надо или дублировать функционал или делать всякие общие библиотек

Что за бред? Видел кучу костылялок с кроном, все всегда спокойно переделывал на cli. Тупо вместо wget localhost/cron.php пишешь php /var/www/cron.php.

Необходимо удалять записи юзеров, которые за полчаса с момента регистрации не прошли по ссылке для активации.

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

Сам бы я сделал именно так. Но мопед не мой =)

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

а что там писать? любой входящий сначала пытается зарегится(скрипт проверяет, был он или нет. А если был, даёт логин/права). Там можно и скрипт cron.php засунуть.

ну я тогда и не знаю, чего ты хочешь…

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

Не надо ничего писать заново. Надо сразу проектировать приложения правильно. Использовать паттерны слабого связывания (DIC, IoC), остерегаться ТТУКов (толстые тупые контроллеры), делать сверхтолстые модели и прочие приёмы.

Когда настанет пора разрабатывать консольный front controller, то сделать это будет проще простого, если все эти принципы соблюдены.

Если cli, надо или дублировать функционал или делать всякие общие библиотеки.

Выше расписал.

Опять же надо про права не забывать, пользователей нужных. Куча проблем на ровном месте.

Тебе chmod/chown трудно сделать? 0_o

Да и post deploy скрипты — обычное дело.

Надо сразу проектировать приложения правильно.

ты выбрал не тот глобус.

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

Добавить к запросу where (regDate + 30min >= now) or (actDate is not null) религия не позволяет? Лишние записи можно удалять скриптом на главной раз в день.