Повторяющиеся события, как их хранить?

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

Я пока знаю два варианта:

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

  2. Храните все будущие события как отдельные события до определенной даты.

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

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

До сих пор я немного читал о RRULE и обнаружил, что могу использовать rrule.js для внешнего интерфейса и несколько других пакетов для внутреннего интерфейса.

Редактировать 1: чтобы лучше уточнить, я не полностью настроен на использование полных стандартов формата iCal и думаю использовать только RRules. Но, возможно, я передумаю, так как я все еще ищу варианты.

Как iCal Vevents и правила должны храниться в БД?


person Cristian    schedule 09.02.2016    source источник


Ответы (1)


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

Предполагая, что последний вариант 1 покрывается RFC5545: вы должны хранить «главный» VEVENT, содержащий базовую информацию, вместе с RRULE, + один VEVENT для каждого экземпляра, который является «исключением» для базового события, где каждое исключение идентифицируется своим RECURRENCE-ID.

В RFC5545 нет ни одного примера такого события, но в RFC5546 есть что-то похожее на https://tools.ietf.org/html/rfc5546#section-4.4.8 (с использованием RDATE вместо RRULE и отсутствие необходимости в свойстве METHOD, но вы поняли идею).

person Arnaud Quillaud    schedule 09.02.2016
comment
Я бы сказал, что вы очень близки к тому, что мне нужно. На данный момент я не настроен на использование полного формата iCal, но, возможно, решу это позже. Примеры немного помогают, но этого недостаточно. Я изо всех сил пытаюсь понять, как выполняется изменение одного события в повторении. Как VEvents должны храниться в БД? - person Cristian; 09.02.2016