-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
(Умный) Планировщик заданий
- Автор темы zerkms
- Дата начала
Fortop
т.е. ты "за" вариант 2?
господа, прошу вас, если вы не согласны с моими вариантами - уточняйте свои реализации. если согласны - то ссылайтесь сразу "решение 1" или "решение 2".
нарезать понты - лучше не здесь, правда.
-~{}~ 05.04.10 01:53:
Fortop
как это коррелирует с "задачей"?
вариант 1 подразумевает: лог УЖЕ ВЫПОЛНИВШИХСЯ ЗАДАНИЙ
в этом логе - факты выполнения заданий, на которые мы ориентируемся.
в варианте 1 нет запланированных задач, запланированные задачи есть в варианте 2.
т.е. ты "за" вариант 2?
господа, прошу вас, если вы не согласны с моими вариантами - уточняйте свои реализации. если согласны - то ссылайтесь сразу "решение 1" или "решение 2".
нарезать понты - лучше не здесь, правда.
-~{}~ 05.04.10 01:53:
Fortop
как это коррелирует с "задачей"?
вариант 1 подразумевает: лог УЖЕ ВЫПОЛНИВШИХСЯ ЗАДАНИЙ
в этом логе - факты выполнения заданий, на которые мы ориентируемся.
в варианте 1 нет запланированных задач, запланированные задачи есть в варианте 2.
и пусть логгирование с обсуждаемым процессом не имеет ничего общего, т.к. проводиться оно должно на другом уровне детализации.
да какая разница
HL или не HL, я лучше напишу простой запрос, чем сложный -~{}~ 05.04.10 01:56:
мде. наверное я не умею объяснять.
начинаем заново всё:
у меня НЕТ НИКАКИХ ПРЕДЛОЖЕНИЙ.
в базе есть только таблицы:
ticket:
id | text | state | user_id | added
user:
id | login
предлагайте решения этой задачи
Fortop
Новичок
zerkms
Я очень смутно понимаю варианты, но 2й мне не нравится.
правильнее 1й вариант, только задача это не "отправка письма пользователю если его долго не было" - а запуск аудитора который проверяет "как давно был пользователь"
Задание может изменить состояние, но его же могут изменить и другие действия (например, вход пользователя.в систему).
Я очень смутно понимаю варианты, но 2й мне не нравится.
правильнее 1й вариант, только задача это не "отправка письма пользователю если его долго не было" - а запуск аудитора который проверяет "как давно был пользователь"
Не, мы ориентируемся на состояния объектов.
Задание может изменить состояние, но его же могут изменить и другие действия (например, вход пользователя.в систему).
Fortop
Новичок
я уже предложил
2 таска
1. раз в один/два/три часа для начальника
2. раз в сутки для исполнителя.
оба проверяют состояние тикетов и если надо шлют уведомление.
-~{}~ 04.04.10 18:06:
соответственно каждый может иметь дополнительную логику.
Например не слать уведомление по одному и тому же вопросу чаще чем раз в сутки.
Для этого можно иметь отдельный storage (индивидуальный для каждого таска) который расширяет возможные состояния рабочих объектов (в данном случае тикетов).
2 таска
1. раз в один/два/три часа для начальника
2. раз в сутки для исполнителя.
оба проверяют состояние тикетов и если надо шлют уведомление.
-~{}~ 04.04.10 18:06:
соответственно каждый может иметь дополнительную логику.
Например не слать уведомление по одному и тому же вопросу чаще чем раз в сутки.
Для этого можно иметь отдельный storage (индивидуальный для каждого таска) который расширяет возможные состояния рабочих объектов (в данном случае тикетов).
Fortop
это решение не удовлетворяет поставленной задаче, потому как при шедуле в раз в сутки ты не сможешь отправить сообщение "через сутки". пессимистичный вариант: "через сутки, 23 часа 59минут и 59 секунд"
если таск запускается ежедневно в 3 ночи, а таск истекает в 3.01 - тогда уведомление придёт с опозданием в почти сутки, что как бы fail.
-~{}~ 05.04.10 02:12:
далее.
где в твоём варианте хранится какая-либо статусная информация?
вот у нас
это решение не удовлетворяет поставленной задаче, потому как при шедуле в раз в сутки ты не сможешь отправить сообщение "через сутки". пессимистичный вариант: "через сутки, 23 часа 59минут и 59 секунд"
если таск запускается ежедневно в 3 ночи, а таск истекает в 3.01 - тогда уведомление придёт с опозданием в почти сутки, что как бы fail.
-~{}~ 05.04.10 02:12:
далее.
где в твоём варианте хранится какая-либо статусная информация?
вот у нас
а как узнать, когда была последняя отправка - ведь нужно отправить "через неделю после последнего уведомления" (что == раз в неделю)
Fortop
недостаточно подробно
т.е. теперь у нас появляется дополнительная таблица (??) со структурой:
entity_id | entity_type | event_type | last_invoked_time
?
-~{}~ 05.04.10 02:20:
недостаточно подробно
т.е. теперь у нас появляется дополнительная таблица (??) со структурой:
entity_id | entity_type | event_type | last_invoked_time
?
-~{}~ 05.04.10 02:20:
мде. и получается решение алгоритмически сложнее второго в разы и при этом во столько же менее точное - в сравнении с моим "вариантом №2" из ТС-поста.
Псевдокот, ага:
event:
id | created_at | period | callable_object | callable_object_method | callable_method_params
по достижению created_at + period дергаем callable_method у callable_object c параметрами callable_method_params где он что-то делает, и в итоге сообщает, нужно ли ему повторно дернуть себя через period либо очистить задание.
типа
event:
id | created_at | period | callable_object | callable_object_method | callable_method_params
по достижению created_at + period дергаем callable_method у callable_object c параметрами callable_method_params где он что-то делает, и в итоге сообщает, нужно ли ему повторно дернуть себя через period либо очистить задание.
типа
PHP:
class Ticket {
function __construct (EventDispatcher $ed) {
$ed::registerEvent('Ticket','notifyBoss', $ticket_id, '2 day');
$ed::registerEvent('Ticket','notifyUser', $ticket_id, '1 day');
}
function notifyBoss($ticket_id) {
if (ticket_open($ticket_id)) {
mail ('[email protected]', 'ticket '.$ticket_id.' expired!');
return true;
} else {
return false;
}
}
}
$ticket = new Ticket();Fortop
Новичок
zerkms
В задаче ничего не было про то, что раз в сутки - должно быть строго через 24 часа.
Т.е. я предположил разумное отклонение 1 сутки при сроках реакции 1 неделя. Надо точнее - уточняй точность.
Это регулируется частотой выполнения аудитора.
Дополнительное состояние можно хранить не отдельно, а добавить в таблицу с тикетом - manager_noticed, chief_noticed (но это негибко), поэтому лучше локальные хранилища для каждого аудитора.
-~{}~ 04.04.10 18:32:
Я даже цитату привел, к чему это относится.
В задаче ничего не было про то, что раз в сутки - должно быть строго через 24 часа.
Т.е. я предположил разумное отклонение 1 сутки при сроках реакции 1 неделя. Надо точнее - уточняй точность.
Это регулируется частотой выполнения аудитора.
Дополнительное состояние можно хранить не отдельно, а добавить в таблицу с тикетом - manager_noticed, chief_noticed (но это негибко), поэтому лучше локальные хранилища для каждого аудитора.
-~{}~ 04.04.10 18:32:
А собственные комментарии читать сложно?
Я даже цитату привел, к чему это относится.