(Умный) Планировщик заданий

[Fortop]

'notifyUser'

Это не

исполнителя А

 

[zerkms]

Fortop
А кого? Давайте перестанем доёбываться?
В моей задаче было уведомление исполнителя и его начальника. Если вы выдумали какие-то свои обозначения - то предупреждайте заранее, ок?
Даже если это не исполнитель, это что-то меняет? Не нужно будет менять задание или что?

 

[Fortop]

Если notifyUser должен известить "текущего" ответственного, то абсолютно фиолетово сколько раз вы этого ответственного исполнителя А будете менять на Б,В и т.д.

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

Поэтому вариант флоппика действительно не имеет проблем, которые описывал Mols

P.S.

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

P.P.S. И судя по Вашей реакции, Вы, в своем варианте №2, предполагали, как раз вариант рассмотренный Mols'ом - т.е. хранить запись о конкретном действии (послать извещение исполнителю А)

 

[zerkms]

Если notifyUser должен известить "текущего" ответственного, то абсолютно фиолетово сколько раз вы этого ответственного исполнителя А будете менять на Б,В и т.д.

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

т.е. если задача будет перераспределена через 23 часа 59 минут, то ещё через минуту новому исполнителю придёт уведомление. верно? о том, что он слишком долго держит тикет???

если это так, то вариант флопика не имеет проблем, описанных Mols, а имеет куда более серьёзные концептуальные проблемы.

P.P.S. И судя по Вашей реакции, Вы, в своем варианте №2, предполагали, как раз вариант рассмотренный Mols'ом - т.е. хранить запись о конкретном действии (послать извещение исполнителю А)

false

 

[Fortop]

zerkms
т.е. если задача будет перераспределена через 23 часа 59 минут, то ещё через минуту новому исполнителю придёт уведомление. верно? о том, что он слишком долго держит тикет???

если это так, то вариант флопика не имеет проблем, описанных Mols, а имеет куда более серьёзные концептуальные проблемы.

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

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

zerkms
false

Врать не надо. Ваша же цитата.

zerkms
создали тикет. распределили на исполнителя А. повешались события об уведомлении А через 1 день.
потом перераспределили на Б.

флоппик не предлагал вешать события об уведомлении А. Поэтому это Ваши личные домыслы о том, как Вы бы решили этот вопрос.

 

[zerkms]

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

повторяю ещё раз, для тех кто в танке: текущая реализация флопика не в состоянии избавиться от этой проблемы без доработки. ты слишком много говоришь абстрактными вещами.
"- если не нужно, то он может сам себя переназначить на новое расчетное время."
как, повторяю КАК "он" может узнать, что НЕ НУЖНО? откуда этот метод получит информацию. давайте без воды и без абстракции.

вот его схема
id | created_at | period | callable_object | callable_object_method | callable_method_params

function __construct (EventDispatcher $ed) {
$ed::registerEvent('Ticket','notifyBoss', $ticket_id, '2 day');
$ed::registerEvent('Ticket','notifyUser', $ticket_id, '1 day');
}

вот его конструктор.

по достижению created_at + period дергаем callable_method у callable_object c параметрами callable_method_params где он что-то делает, и в итоге сообщает, нужно ли ему повторно дернуть себя через period либо очистить задание.

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

ситуация:
создали тикет, 12 часов дня, 4 апреля. в базу добавилась запись о нотификации исполнителя, согласно схемы таблицы в виде:
created_at: 2010-04-04 12:00:00, period: 86400

5 апреля в 11:59 меняем исполнителя с А на Б
5 апреля в 12:00: согласно заданию работает код по отправке уведомления пользователю Б

epic fail.

флоппик не предлагал вешать события об уведомлении А.

$ed::registerEvent('Ticket','notifyUser', $ticket_id, '1 day');

это тогда что? это уведомление кого?.

Врать не надо. Ваша же цитата.

цитата моя. умозаключения из цитаты твои. неверные.

 

[Fortop]

zerkms
текущая реализация флопика не в состоянии избавиться от этой проблемы без доработки

Охренеть. А это ни о чем не говорит

флоппик
Псевдокот, ага:

Равно как и пропущенная реализация метода noticeUser?
Но самое смешное, проблема есть только у Вас? потому что Вы не понимаете одной простой разницы:

В шедулере будет храниться запись о времени выполнения кода ответственного за логику отправлять/неотправлять/переназначить.
А не отправить текущему исполнителю

zerkms
откуда этот метод получит информацию. давайте без воды и без абстракции.

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

Если нужна реализация - то где ТЗ и бюджет?
В противном случае я не понимаю какую конкретику я могу выдать.

Где она(информация) у Вас лежит оттуда он ее и получит и это(получение информации) в методе заложите Вы собственными руками.

Есть таблица пользователей, есть таблица тикетов.
есть таблица связей пользователь-тикет с временем назначения.

Если Вы хотите использовать какие-то настройки (например, иметь возможность изменения времени отправки сообщения с 24ч на 48ч и т.д.), то и это Вы должны предусмотреть.

zerkms
5 апреля в 12:00: согласно заданию работает код по отправке уведомления пользователю Б

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

это тогда что? это уведомление кого?.

Это уведомление того, кого Вы захотите.
В Вашем случае - текущего пользователя(а не конкретного А) ответственного за тикет.

zerkms
вот цитата флоппика, свидетельствующая о том, что для каждого задания в базе будет запись с временем запуска.

Все я не могу. И что что оно будет?
Это запись не с временем отправки письма, а запись с временем запуска проверки, нужно ли по данному тикету отправить письмо!!!!!!!

Сравните

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

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

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

-~{}~ 05.04.10 01:11:

zerkms
Без обид - но я не могу так общаться.

Я прекрасно понимаю ограниченность своих возможностей объяснять людям, которые не понимают, и меня это(ограниченность моих возможностей) крайне бесит!

Поэтому если Вы и теперь не поняли - я пас.

 

[zerkms]

Кто из нас двоих знает детали проектируемой системы?
Вы как тот волшебный клиент, постоянно достаете что-то новое из рукава, пытаясь оказаться правым.

я ничего не дёргаю. задача с первой страницы не изменялась.

Где она(информация) у Вас лежит оттуда он ее и получит и это(получение информации) в методе заложите Вы собственными руками.

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

Это запись не с временем отправки письма, а запись с временем запуска проверки, нужно ли по данному тикету отправить письмо!!!!!!!

да. и по данному тикету будет отправлено письмо. через 1 минуту после назначения тикета НОВОМУ исполнителю о том, что он его СЛИШКОМ ДОЛГО ДЕЛАЕТ. epic fail.

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

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

Поэтому если Вы и теперь не поняли - я пас.

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

 

[Fortop]

Жесть, флоппик, попробуй объяснить ты человеку.
Я реально не могу смотреть на этот фарс.
И эти люди еще пишут фреймворки - убиться и не встать.

zerkms
и по данному тикету будет отправлено письмо. через 1 минуту после назначения тикета НОВОМУ исполнителю о том, что он его СЛИШКОМ ДОЛГО ДЕЛАЕТ. epic fail.

Почему? Почему автор кода не может поставить проверку о том, сколько времени прошло с момента назначения тикета текущему пользователю?
Чего не хватает автору чтобы сделать эту простую вещь?
Какого хрена, я со своим копеечным опытом в php должен пытаться объяснить эту тривиальщину профессиональному (?) разработчику?

zerkms
а коду неоткуда брать информацию

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

И да,

Fortop
есть таблица связей пользователь-тикет с временем назначения.

Реальный epic fail!
Бросайте программирование - не Ваше это.

 

[zerkms]

Почему? Почему автор кода не может поставить проверку о том, сколько времени прошло с момента назначения тикета текущему пользователю?

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

Чего не хватает автору чтобы сделать эту простую вещь?

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

Какого хрена, я со своим копеечным опытом в php должен пытаться объяснить эту тривиальщину профессиональному (?) разработчику?

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

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

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

-~{}~ 05.04.10 09:39:

есть таблица связей пользователь-тикет с временем назначения.

она не "есть", она волшебно появилась, чтобы притянуть решение за уши.

 

[Fortop]

В сад....

В детский.

 

[dr-sm]

первый вариант, скорее всего, лучше, меджык симплисити рулит что-то в последнее время.

PS. если я правильно понял позицию Fortop, то он предлагает сначала второй вариант делать, а потом, в момент отправки еще и первый только для каждого айтема отдельно.
хотя мне досихпор непонятно, зачем я прочитал эти 5 страниц о_О

 

[Fortop]

dr-sm
то он предлагает сначала второй вариант делать

Я уже ничего не предлагаю.
У zerkms есть свои сферические кони, особенности которых знает только он.

Что-либо советовать в такой позиции - идиотизм. А я повелся.

 

[zerkms]

меджык симплисити рулит что-то в последнее время.

симплисити чего? алгоритмы там будут сложнее.

-~{}~ 05.04.10 09:57:

У zerkms есть свои сферические кони, особенности которых знает только он.

я привел конкретную схему базы, я достаточно подробно сформулировал требования, я достаточно подробно описывал use case'ы своих решений.
в отличие от твоих предложений - которые постоянно были с недоговорками и от поста к посту появлялись какие-то новые детали, которые кардинальным образом меняли всё.

 

[korchasa]

Fortop
На пальцах, насколько я понял:

Вариант номер 1: Раз в n-дцать секунд запускаем скрипт check_overhead_in_tickets.php, который, в соответствии с данными из базы, находит тикеты с превышением времени и т.д. В тикет придется добавлять поле assert_time, чтобы по нему смотреть. Чтобы не слать по тридцать раз фиксируем уведомления в отдельной таблице, или флагом в таблице тикетов.

Вариант номер 2: Во время создания тикета (!) в таблицу уведомлений добавляем запись {id-исполнителя, время отправки, текст}. При изменении исполнителя старые записи для этого тикета удаляем, добавляем новую.

Вариант номер твой(или чей-то еще, я уже потерял нить): Вариант номер два, но вместо текста пишем данные и callback, который надо дернуть. Желание стандартизировать callback по количеству параметров, и оставить в них только тикет это хорошо, но в данном случае это ведет к шаманству с реинициализацией, с вытекающими радостями на отладке.

 

[Fortop]

korchasa
Я в упор не вижу кардинальной разницы между описанным Вами вариантом №1 и тем, о чем говорил я.

Fortop
правильнее 1й вариант, только задача это не "отправка письма пользователю если его долго не было" - а запуск аудитора который проверяет "как давно был пользователь"

чем это отличается от Вашего

скрипт check_overhead_in_tickets.php, который, в соответствии с данными из базы, находит тикеты с превышением времени и т.д.

?

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

Причем тут стандартизация callback по параметрам. И в чем заключается шаманство с реинициализацией - я не понимаю.

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

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

1й вариант - делаем только тогда, когда надо и только с тем, что надо.
2й вариант - мы постоянно делаем дурную работу, добавили, удалили, добавили, удалили ...

 

[korchasa]

Автор оригинала: Fortop
чем это отличается от Вашего?

Ничем

Автор оригинала: Fortop
Причем тут стандартизация callback по параметрам. И в чем заключается шаманство с реинициализацией - я не понимаю.

При том, что в предложенном варианте ed::registerEvent('Ticket','notifyBoss', $ticket_id, '2 day'); недостаточно информации не только для формирования письма, но и для принятия решения о том, кому надо отправлять. Следовательно в таблицу тикетов добавится лишнее поле для отслеживания времени, когда на исполнителя был повешен тикет. Шаманство с реинициализацией заключается в ней самой, т.к. данных по которым принято решение реинициализироваться в чистом виде нет. Точнее не обязательно есть, т.к. могут быть уже затерты. Тут уж unit-тесты и info-записи в лог, а ля "я это сделал потому что...".

Автор оригинала: Fortop
В чем интересность варианта 2, когда надо втупую писать лишние события, чтобы их потом удалить (например, при смене исполнителя, при логине пользователя и т.д.) - я не понимаю.

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

 

[Fortop]

korchasa
недостаточно информации не только для формирования письма, но и для принятия решения о том, кому надо отправлять.

Все правильно. Это очевидно, и на мой взгляд, достаточно логично. Поскольку требуемую информацию, насколько я понял, callback достанет сам, согласно своей логики.
Именно поэтому я и воспринимаю предложение флоппик, как вариацию на тему №1.

korchasa
Следовательно в таблицу тикетов добавится лишнее поле для отслеживания времени, когда на исполнителя был повешен тикет

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

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

korchasa
В том, что сам скрипт рассылающий уведомления туп до безобразия.

Не менее туп, чем в альтернативном варианте.
Отсутствует промежуточный слой (имеющийся в варианте №1), зато операции редактирования/добавления нагружены дополнительной логикой. Это преимущество?

 

[zerkms]

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

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

 

[Mols]

zerkms
В предложении флоппика нет привязки к конкретному исполнителю или боссу.
Он предлагает регистрировать вызыв метода notifyBoss и notifyUser для Объекта Ticket.
То есть как раз смена пользователя будет отработана нормально.
Но вот смысла регистрировать отдельно notifyBoss и notifyUser да ещё и для каждого тикета отдельно - не вижу.
Всё равно придётся проверять активен ли тикет или нет. И чистить эту кучу.
Ситуация со сменой пользователя уже понятна.
Похожая ситуация. Создали тикет. Исполнитель посмотрел - говорит " я в другой задаче делаю функционал, который очень пригодится здесь. Упростит разработку и т.д и т.п" Ну в общем надо приостановить выполнение этой задачи скажем на месяц.
Нужно вводить новое состояние задачи "приостановлено". И опять возникают вопросы поиска этих назначенных заданий для всех пользователей которые относятся к объекту (сейча тикету) и т.д и т.п.
Либо нужно в сами эти назначенные задания добавлять логику определения нужно ли отсылать для объекта извещения (а это ж вроде как раз то, от чего хотели уйти).
Ну ИМХО не нужно это всё. В одном месте всё должно быть.

-~{}~ 05.04.10 10:59:

Сорри))) чето я прощёлкал, что тут уже 5 страниц. Немного лишнего написал.