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

[флоппик]

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

т.е. они решают разные проблемы? )

 

[zerkms]

не совсем. я писал, что в зависимости от результатов работы функции (в нашем случае true/false) шудулер либо удалит, либо продлит задание.

и? т.е. ты можешь удалить задание, а я нет?

По моему мнению, с _теоретической_ точки зрения нет никакой разницы между первым и вторым описанием решения, которые ты привел.

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

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

а я во втором варианте ТС поста что же тогда предлагаю хранить?
процитирую в N-ный раз:

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

-~{}~ 05.04.10 03:04:

т.е. они решают разные проблемы? )

они решают одну проблему разными способами. поэтому это разные варианты.

 

[флоппик]

Прочти свои слова:

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

по моему, хранить лог совершеннных действий, и перечень будущих - разные проблемы, нет?

 

[zerkms]

флоппик
проблема == рассылка уведомлений.
как она будет решена == это не проблема, это решение

 

[Fortop]

частного решения ты не предложил

Уф. Я просто не понимаю что от меня надо?
Я должен дать готовый код?

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

В конкретном случае извещения - да, это может быть одна общая таблица и для Исполнителя и для Начальника.
Что-то вида

ticked_id, type  = enum(user, chief), noticed = date

 

[флоппик]

zerkms, обьясни, как хранение лога совершенных действий решит проблему рассылки уведомлений?

 

[zerkms]

zerkms, обьясни, как хранение лога совершенных действий решит проблему рассылки уведомлений?

легко.
я даже писал на первой странице запрос http://phpclub.ru/talk/showthread.php?postid=896059#post896059

Уф. Я просто не понимаю что от меня надо?
Я должен дать готовый код?

не готовый код, а структуру, в которой будут храниться дополнительные данные, на основе которых будет работать твоё предложение.

ticked_id, type = enum(user, chief), noticed = date

т.е. noticed == уведомлённый. т.е. мой вариант 1? т.е. в этой табле лежит история уведомлений?

 

[Fortop]

zerkms
не готовый код, а структуру, в которой будут храниться дополнительные данные, на основе которых будет работать твоё предложение.

Она разная для разных случаев.
Для случая с уведомлениями я привел.

zerkms
т.е. noticed == уведомлённый. т.е. мой вариант 1? т.е. в этой табле лежит история уведомлений?

Да, как один из вариантов.

 

[флоппик]

легко.
я даже писал на первой странице запрос http://phpclub.ru/talk/showthread.p...6059#post896059

эээ... т.е. ты говоришь о логе ВСЕХ событий(не уведомлений)?

Тогда боюсь почти все присутствущие спутали первый вариант и второй между собой.

 

[zerkms]

Да, как один из вариантов.

итого:
ты предложил мой вариант №1 (с оговоркой, что могут быть иные случаи, но тем не менее - один в один)
флоппик предложил мой вариант №2

различия в том, что я говорю "шедулер" - вы говорите "аудитор"

флуда - 3 страницы.

мораль?

-~{}~ 05.04.10 03:24:

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

ни мои решения, ни твоё - не зациклены на отправке почты.

 

[Fortop]

различия в том, что я говорю "шедулер" - вы говорите "аудитор"

флуда - 3 страницы.

мораль?

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

 

[zerkms]

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

 

[Mols]

Я бы выбрал вариант 1.
Запуск системы и поиск извещений которые пора отправить.
Если я всё правильно понял, то в варианте 2 создание тикера приведёт к внесению записей
1. Уведомить исполнителя если тикет не просмотрен до (время1)
2. Уведомить босса если тикет не просмотрен до (время1)
Получается, что действие "просмотр тикета" со стороны исполнителя должно удалять(помечать) записи относящиеся не только к самому исполнителю. Сделать привязку конкретно к тикету - тоже вряд ли удастся. В таблице ведь предполагается хранить все возможные извещения, а они будут относится не только к тикетам. В общем наверняка получится громоздкая логика определения какое действие какие записи должно модифицировать (просмотр тикета - должен удалить записи к получателям)
Кроме того, если понадобится ввести новый тип извещений(или ещё одного субъекта которого надо известить). В варианте 2 - придётся дописывать эти извещения для всех объектов. Учитывая что конкретно определить объект действие над которым должно вызывать изменения таблицы извещений проблематично - головняк ещё тот.

Вариант 1 вроде как удобнее. Необходимо что-то добавить - изменил логику поиска событий требующих уведомления и при следующем же запуске скрипта всё отработает. (Ну вот например появится ещё 3 субъект которого надо уведомлять - нет проблем)
Как-то так.

 

[zerkms]

Mols
в варианте 1 проблематичнее определять нужно ли отослать извещение.

 

[Mols]

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

 

[флоппик]

Mols
ты не смотрел мой псевдокод? в нем нет всех описанных тобой проблем. А zerkms считает, что это он реализует второй вариант, и я допускаю, что в его терминах он прав.

 

[Mols]

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

-~{}~ 04.04.10 21:00:

Но я бы отказался от регистрации "событий" для каждого тикета. Думаю сделал бы интерфейс вида sendNotify и все объекты, которые могут потребовать извещений реализовывали бы этот интерфейс. А внутри sendNotify уже выполнялся бы поиск всех экземпляров по которым надо разослать извещения.

 

[zerkms]

а он вроде как уже подготовленные для адресата сообщения хотел вносить в таблицу.

я просто частный пример привёл в первом посте. и сразу же после этого примера перешёл на термин "задание".

-~{}~ 05.04.10 07:40:

ты не смотрел мой псевдокод? в нем нет всех описанных тобой проблем.

флоппик
вообще - в нём есть абсолютно те же проблемы.

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

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

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

 

[Fortop]

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

Где это у флоппик?

 

[zerkms]

Fortop
я же привёл цитату.

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