под повторяющимися интервалами имеется в виду следующее: какое-то событие повторяется в 11:00-12:00 по понедельникам, или каждый день с часу до двух, или раз в год ну и и.т.д
если нет для плюсов, подойдет для любого другого языка
Здравствуйте, qadmium, Вы писали:
Q>Посдкажите плиз библиотеку для работы с сабжем
А какого рода работа с сабжем?
К примеру, в WinMobile такие функции были у аутлуковского календаря, но поиск события по заданной дате-времени превращался в линейный. (Для однократных событий, ясное дело, поиск логарифмический). Из-за этого календарные приложения ощутимо тормозили, если напихать в базу календаря множество повторяющихся событий.
Так что вижу два варианта:
— тупой (легко программируется, приемлемо работает на небольших наборах) — несортированная коллекция и линейный поиск
— затейливый (требует нетривиальной организации базы данных, чтобы приемлемо работать на больших наборах)
Вопрос в том, какой характерный размер набора данных, характерный диапазон дат, и характерные операции.
Для небольшого диапазона дат можно размножить каждое повторяемое событие (возможно, с отсылкой к исходному шаблону) и накидать в базу.
Для не слишком интенсивного потока запросов "когда ближайшее событие?" — как, скажем, в cron'е, — можно позволить себе делать тотальный забег по базе.
Для библиотек визуализации, а также для серверов, — придётся задуматься о кешировании запросов-ответов.
nextEvent(fromDate), "маппинг"(или как это правильно назвать?) на временную шкалу, нахождение пересечений между интервалами
что-то близкое к теме я нашел у Фаулера — http://martinfowler.com/apsupp/recurring.pdf, но он на четвертой странице объявляет метод Date nextOccurence (String eventArg, Date aDate), но его реализацию оставляет на усмотрение читателя, а как это реализовать с помощью его интерпретатора я не представляю
Здравствуйте, qadmium, Вы писали:
Q>Вообщем нужно все и сразу
Сколько событий-то в базе?
Q>из основных операций необходимо что-то типа Q>nextEvent(fromDate), Q>"маппинг"(или как это правильно назвать?) на временную шкалу,
Отображение на временную шкалу
— это либо предельно просто: делаем забег от fromDate по всем nextEvent() до toDate; нам ведь всё равно нужно все точки получить
— либо достаточно сложно: находим множество повторяющихся событий (каждое из которых потом даст нам россыпь точек на временной шкале)
Q>нахождение пересечений между интервалами
Имеется в виду нахождение пересечения между одним конкретным отрезком (повтором) события и другим таким же конкретным отрезком,
или нужно найти повторяемое событие, являющееся пересечением двух других?
Например: "ежемесячно 13 числа" * "еженедельно в пятницу" = "каждую пятницу-13". Это событие, которое повторяется 2-3 раза в год, и полный цикл там 4 года (а с учётом поправок к високосности — то вообще 400 лет).
Q>что-то близкое к теме я нашел у Фаулера — http://martinfowler.com/apsupp/recurring.pdf, но он на четвертой странице объявляет метод Date nextOccurence (String eventArg, Date aDate), но его реализацию оставляет на усмотрение читателя, а как это реализовать с помощью его интерпретатора я не представляю
У него упор делается на интерфейс, а не на реализацию. Реализация там дубовая: линейный поиск, причём в хардкорном ООП-ява-стиле: while/return/next
Для небольшого количества событий это более чем оправдано, в силу прозрачности алгоритмов.
Я в cron не копался, но полагаю, что cron тоже каждый раз все свои crontab'ы проверяет от начала до конца.
Если же пишем высокопроизводительное приложение (даже GUI календаря, в некоторых случаях) — то придётся исхитряться.
Поэтому и уточняю: характерный объём данных и характерное использование, с ограничением времени отклика.
Тот же GUI можно сделать с дорисовкой по мере нахождения ответа.
Здравствуйте, Кодт, Вы писали:
К>Сколько событий-то в базе?
Да нет базы, это гуй и весьма мпецефичный запросы на сервер с учетом этих интервалов
К>Отображение на временную шкалу К>- это либо предельно просто: делаем забег от fromDate по всем nextEvent() до toDate; нам ведь всё равно нужно все точки получить
как бы и так сойдет, вопрос только в эффективном нахождении nextEvent()
К>или нужно найти повторяемое событие, являющееся пересечением двух других?
ога, вообщем то я уже начал думать в сторону фаулера, так вот из его реализации можно сформировать IntersectionTE который в итоге будет пуст(например 3 число каждого месяца и 5 число каждого месяца), и как это проверить я хз
не знаю, может доработать его вариант, только чтобы каждое TemporalExpression предоставляло некоторый интерфейс, чтобы другие TemporalExpression's могли определить через него, могут ли они пересечься в принципе
К>У него упор делается на интерфейс, а не на реализацию. Реализация там дубовая: линейный поиск, причём в хардкорном ООП-ява-стиле: while/return/next К>Для небольшого количества событий это более чем оправдано, в силу прозрачности алгоритмов.
событий немного (пока, потом требования могут поменяться, как всегда вообщем-то) в основном это что-то типа с "5 вечера до 8 утра" каждый вторник кроме праздников.
Короче на данный момент есть только события типа: каждый день (+ время с какого-по-какое) и каждый N день недели (+ время с какого-по-какое), не больше двух десятков на неделю (Надеюсь доступно объяснил )
Здравствуйте, qadmium, Вы писали:
К>>Сколько событий-то в базе? Q>Да нет базы, это гуй и весьма мпецефичный запросы на сервер с учетом этих интервалов
База, приколоченная гвоздями прямо в тексте программы — всё равно база. Я ж не говорю про SQL-сервер, а абстрактно.
Q>Короче на данный момент есть только события типа: каждый день (+ время с какого-по-какое) и каждый N день недели (+ время с какого-по-какое), не больше двух десятков на неделю (Надеюсь доступно объяснил )
Тогда для каждого вида события пишешь функцию: nextOccurence(fromDate).
Для однократных событий это, понятно, сводится к проверке fromDate < theDate. (Иначе — вернуть +оо или NULL, по вкусу).
Для ежедневных — разбить fromDate на дату и время, посмотреть theTime меньше или больше, и склеить обратно (прибавив к дате 1 день, при необходимости).
Для еженедельных — аналогично, только разбить ещё и на недели.
Кстати, обычно еженедельные события — не штучные, а с некоторой маской: "по понедельникам, средам, пятницам". То есть, разбиваешь fromDate на недели/день/время; смотришь, какой день маски ближе всего, ну и так далее.
А потом среди всего множества событий — вызываешь у каждого nextOccurence и берёшь минимум.
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, qadmium, Вы писали:
К>>>Сколько событий-то в базе? Q>>Да нет базы, это гуй и весьма мпецефичный запросы на сервер с учетом этих интервалов
К>База, приколоченная гвоздями прямо в тексте программы — всё равно база. Я ж не говорю про SQL-сервер, а абстрактно.
Q>>Короче на данный момент есть только события типа: каждый день (+ время с какого-по-какое) и каждый N день недели (+ время с какого-по-какое), не больше двух десятков на неделю (Надеюсь доступно объяснил )
К>Тогда для каждого вида события пишешь функцию: nextOccurence(fromDate). К>Для однократных событий это, понятно, сводится к проверке fromDate < theDate. (Иначе — вернуть +оо или NULL, по вкусу). К>Для ежедневных — разбить fromDate на дату и время, посмотреть theTime меньше или больше, и склеить обратно (прибавив к дате 1 день, при необходимости). К>Для еженедельных — аналогично, только разбить ещё и на недели. К>Кстати, обычно еженедельные события — не штучные, а с некоторой маской: "по понедельникам, средам, пятницам". То есть, разбиваешь fromDate на недели/день/время; смотришь, какой день маски ближе всего, ну и так далее.
К>А потом среди всего множества событий — вызываешь у каждого nextOccurence и берёшь минимум.
в обшем примерно так сейчас и есть, только кол-во говнокода почему то уже ушло за 2000 строк
Перекуём баги на фичи!
