(Умный) Планировщик заданий
- Автор темы zerkms
- Дата начала
относительно реализации я бы сделал notifySubscribers()
который не обязательно будет вызван именно шедулером, а так же и изменениями тикета, например.
Целью моего псевдокода было показать разумное разделение отвественности между обьектами приложения, как то показать то, что планировать эти самые "извещения" должен сам обьект, о изменении состояния которого извещают (достижение определенного времени это тоже изменение состояния) Причем, как zerkms сначала сказал, что "никто не говорит, что это обязательно уведомления" - это могут быть любые изменения состояния. Да и сами уведомления могут быть реализованы различными способами.
Я пока придерживаюсь мнения Foxtrop, zerkms и правда постоянно какие то новые граничные условия вытаскивает на божий свет, и утверждает, что "это все так и было задумано и не имеет принципиальной разницы"
А весь срач вокруг моего кода только потому, что я пока единственный, кто сумел выразить свои мысли в однозначной терминологии (сложно говорить о неоднозначности псевдокода, ага), тогда как остальные оперируют на уровне литературных изысков, т.к. уровень знания технической терминологии тут у всех разный.
Пхпклуб такой пхпклуб, ага.
который не обязательно будет вызван именно шедулером, а так же и изменениями тикета, например.
Целью моего псевдокода было показать разумное разделение отвественности между обьектами приложения, как то показать то, что планировать эти самые "извещения" должен сам обьект, о изменении состояния которого извещают (достижение определенного времени это тоже изменение состояния) Причем, как zerkms сначала сказал, что "никто не говорит, что это обязательно уведомления" - это могут быть любые изменения состояния. Да и сами уведомления могут быть реализованы различными способами.
Я пока придерживаюсь мнения Foxtrop, zerkms и правда постоянно какие то новые граничные условия вытаскивает на божий свет, и утверждает, что "это все так и было задумано и не имеет принципиальной разницы"
А весь срач вокруг моего кода только потому, что я пока единственный, кто сумел выразить свои мысли в однозначной терминологии (сложно говорить о неоднозначности псевдокода, ага), тогда как остальные оперируют на уровне литературных изысков, т.к. уровень знания технической терминологии тут у всех разный.
Пхпклуб такой пхпклуб, ага.
Fortop
Новичок
В который раз убеждаюсь, спрашивающие на форумах, имеют кучу гонора и святую веру в непогрешимость собственной точки зрения.
Зато не имеют понятия о чем спрашивают и любят задавать вопросы в форме - "как вырвать гланды через жопу, правильные варианты не предлагать".
Если человек с датой регистрации 2004й год ведет себя так, то что можно требовать от начинающих?
Печально все это господа.
Fortop
потому что остальные таблицы не имеют значения для решения данной задачи.
я дал минимально необходимый набор таблиц + развязал руки: нужны ещё таблицы - говорите какие.
лично я привык общаться со специалистами, которые что-то подразумевают явно, а не занимаются философией и гаданием а-ля "для таких задач обычно делают так".
неужели так сложно в рамках поставленной задачи явно общаться? оперируя известными таблицами и извещая обо всех "подразумеваниях"? или это такая специфика гур - в течение разговора надумать себе в голове структуру из 100 таблиц и считать, что все знают, что у тебя там творится?
я не хочу завязываться на ИМЕЮЩУЮСЯ структуру - для этого я и дал МИНИМУМ. чтобы не притягивать за уши решение к тому что есть, а из 2х реалий: того что есть и того что нужно сделать - получить симбиоз, который удовлетворит всех.
-~{}~ 05.04.10 23:31:
а человек с датой регистрации 2010г в течение всего разговора что-то там у себя в голове нарисовал и вместо того, чтобы поделиться действительно необходимой структурой - нарезал понты.
потому что остальные таблицы не имеют значения для решения данной задачи.
я дал минимально необходимый набор таблиц + развязал руки: нужны ещё таблицы - говорите какие.
лично я привык общаться со специалистами, которые что-то подразумевают явно, а не занимаются философией и гаданием а-ля "для таких задач обычно делают так".
неужели так сложно в рамках поставленной задачи явно общаться? оперируя известными таблицами и извещая обо всех "подразумеваниях"? или это такая специфика гур - в течение разговора надумать себе в голове структуру из 100 таблиц и считать, что все знают, что у тебя там творится?
я не хочу завязываться на ИМЕЮЩУЮСЯ структуру - для этого я и дал МИНИМУМ. чтобы не притягивать за уши решение к тому что есть, а из 2х реалий: того что есть и того что нужно сделать - получить симбиоз, который удовлетворит всех.
-~{}~ 05.04.10 23:31:
в том-то и дело, что человек с датой регистрации 2004г очертил задачу более чем явно, дал список таблиц и описал их структуру.
а человек с датой регистрации 2010г в течение всего разговора что-то там у себя в голове нарисовал и вместо того, чтобы поделиться действительно необходимой структурой - нарезал понты.
Mols
Новичок
zerkms
Какое отношение события имеют к планировщику, и тем более к логике которую нужно выполнить по расписанию в планировщике?
В рамках описанной задачи вроде как надо выполнить определённую логику в определённое время. И я вообще предлагаю выполнять её периодически не привязываясь к тому, были созданы тикеты или нет.
-~{}~ 05.04.10 16:07:
Ровно как и написано в варианте 1.
Какое отношение события имеют к планировщику, и тем более к логике которую нужно выполнить по расписанию в планировщике?
В рамках описанной задачи вроде как надо выполнить определённую логику в определённое время. И я вообще предлагаю выполнять её периодически не привязываясь к тому, были созданы тикеты или нет.
-~{}~ 05.04.10 16:07:
Ровно как и написано в варианте 1.
Mols
Новичок
zerkms
Без претензий на панацею.
Общую концепцию того, чтобы выбрал я - уже написал тут.
Хоть в базе их регистрируйте, хоть просто скрипт в крон(лучшего шедулера кстати наверное и желать не надо. Из базы без крона тоже не дёрнешь).
Но делать вариант 2 - ИМХО значит обречь себя на написание просто очень запутанной логики, которая будет поддерживать таблицу заданий в актуальном состоянии.
Без претензий на панацею.
Общую концепцию того, чтобы выбрал я - уже написал тут.
(Возможно не sendNotify а getAllNotify и рассылку отдельным модулем. Думать ещё надо.)
Хоть в базе их регистрируйте, хоть просто скрипт в крон(лучшего шедулера кстати наверное и желать не надо. Из базы без крона тоже не дёрнешь).
Но делать вариант 2 - ИМХО значит обречь себя на написание просто очень запутанной логики, которая будет поддерживать таблицу заданий в актуальном состоянии.
Mols
не совсем понимаю
%)
плюс, как я уже много раз предлагал - давайте рассмотрим usecase этого подхода, что и как будет искаться:
ticket:
id | text | state | user_id | added
user:
id | login
вот схема данных, которая у нас есть. разрешены ЛЮБЫЕ ЕЁ МОДИФИКАЦИИ: можно изменять текущий набор полей (но лишь бы те же данные можно было уместить в новой схеме) + добавлять новые таблицы.
что делаем дальше? какие поля и куда добавляем?
напоминаю - нам нужно теперь найти тикеты, по которым нужно произвести действие "рассылка уведомлений разным людям"
(я расспрашиваю не потому, что я совершенно не понимаю, что вы имеете ввиду - а потому, что у этой реализации есть серьёзные проблемы с выборками интересующих данных, но хочу чтобы вы сами их обнаружили - ну или чтобы показали, что всё таки прекрасно и я паникую зря)
не совсем понимаю
т.е. sendNotify - это интерфейс, который реализует "тикет" (класс ticket). и речь вроде идёт о конкретном экземпляре объекта
а тут говорится о методе поиска объектов
%)
плюс, как я уже много раз предлагал - давайте рассмотрим usecase этого подхода, что и как будет искаться:
ticket:
id | text | state | user_id | added
user:
id | login
вот схема данных, которая у нас есть. разрешены ЛЮБЫЕ ЕЁ МОДИФИКАЦИИ: можно изменять текущий набор полей (но лишь бы те же данные можно было уместить в новой схеме) + добавлять новые таблицы.
что делаем дальше? какие поля и куда добавляем?
напоминаю - нам нужно теперь найти тикеты, по которым нужно произвести действие "рассылка уведомлений разным людям"
(я расспрашиваю не потому, что я совершенно не понимаю, что вы имеете ввиду - а потому, что у этой реализации есть серьёзные проблемы с выборками интересующих данных, но хочу чтобы вы сами их обнаружили - ну или чтобы показали, что всё таки прекрасно и я паникую зря)
Mols
Новичок
roles:
id | name
user:
id | login | role_id
ticket_actions:
id | ticket_id | action_id | user_id | datetime
ticket_to_user
id | ticket_id | user_ud | datetime
Понятно что любые операции с тикетом должны заполнять ticket_actions. Пока остановимся на том, что есть три операции "добавлен" "назначен" и "просмотрен".
Избавьте меня от написания СКЛ запросов и кода класса Тикет.
Но думаю не составит труда заносить все действия над тикетом в ticket_actions и определить когда был добавлен исполнитель в тикет. И что прошло более суток и он ещё не просмотрел задачу.
Далее в sendNotify() (само назнвание возможно неудачное, может быть лучше вариант Флоппика)
1. Надо найти все такие тикеты
2. Оповестить пользователей с теми ролями которые а) привязаны к тикету; б) должны быть оповещены об этой ситуации.
Таблицу с извещениями - тоже думаю не очень сложно сделать.
Далее - добавите логику "Делает больше недели" и т.д и т.п.
id | name
user:
id | login | role_id
ticket_actions:
id | ticket_id | action_id | user_id | datetime
ticket_to_user
id | ticket_id | user_ud | datetime
Понятно что любые операции с тикетом должны заполнять ticket_actions. Пока остановимся на том, что есть три операции "добавлен" "назначен" и "просмотрен".
Избавьте меня от написания СКЛ запросов и кода класса Тикет.
Но думаю не составит труда заносить все действия над тикетом в ticket_actions и определить когда был добавлен исполнитель в тикет. И что прошло более суток и он ещё не просмотрел задачу.
Далее в sendNotify() (само назнвание возможно неудачное, может быть лучше вариант Флоппика)
1. Надо найти все такие тикеты
2. Оповестить пользователей с теми ролями которые а) привязаны к тикету; б) должны быть оповещены об этой ситуации.
Таблицу с извещениями - тоже думаю не очень сложно сделать.
Далее - добавите логику "Делает больше недели" и т.д и т.п.
угу, я паниковал таки зря - всё ок.
предложение:
мысли насчёт этого?
предложение:
если представить - что уведомление о тикетах - специфичная для сущности тикет задача (иными словами - в системе больше не будет подобных вещей), тогда можно события уведомлений писать в ticket_actions тоже
мысли насчёт этого?
Mols
Новичок
zerkms
Ну опять же смотреть по месту.
В данной структуре есть инициатор события - user_id. Можно для системных делать нулл. Ну не знаю в общем. Надо смотреть. Это ж всё на коленке и "в общих чертах". А детально сорри. И так довольно много времени ушло. Без обид)))
-~{}~ 05.04.10 17:21:
Да и структуру ещё думать надо....
-~{}~ 05.04.10 17:24:
Например роль наверное придётся таки в рамках ticket_to_user делать. Именно в рамках задачи... может же быть человек боссом для одной задачи и исполнителем для другой.
Ну опять же смотреть по месту.
В данной структуре есть инициатор события - user_id. Можно для системных делать нулл. Ну не знаю в общем. Надо смотреть. Это ж всё на коленке и "в общих чертах". А детально сорри. И так довольно много времени ушло. Без обид)))
-~{}~ 05.04.10 17:21:
Да и структуру ещё думать надо....
-~{}~ 05.04.10 17:24:
Например роль наверное придётся таки в рамках ticket_to_user делать. Именно в рамках задачи... может же быть человек боссом для одной задачи и исполнителем для другой.
как это решает проблему
извиняюсь если что, не осилил всё что дальше первой страницы, но с первого поста задача показалась элементарной.
приводя к нормали, описынные требования(с первой страницы) - поверка действий пользователя, будь то логин в систему, или просмотр тикета, оплата счёта.... зачем для этого создавать таблицы действие над тикетов, таблица входов, таблицу платежей. А какие случаи при эвенте делать, это уже другая задача, почти никак не связаная.
извиняюсь если что, не осилил всё что дальше первой страницы, но с первого поста задача показалась элементарной.