For instance something like Google Calendar, where we can:
Add simple event
Add recurring event
every week
every monday/tuesday
etc.
Delete an instance of a recurring event
Change all following recurrent event
etc.
I have an events with the primary event "Event#1" for instance and its instances "Event#2" and "Event#3" that have an event_id foreign key to the primary event, e.g. 1
What do you think? Should I use the iCal spec somehow?
Two key things:
Split the event from its schedule.
Split the recurring schedule definition from its individual schedule.
By splitting the event from its schedule, instances of a recurring event can share the same event information like its description and location, while others can use an edited version.
events:
id
name
description
location
...
By splitting the recurring schedule from its individual schedule makes querying for events much simpler.
recurring_event_schedules:
id
event_id
schedule: jsonb
start_at: timestamp with time zone
This is the recurring schedule for an event.
Recurring schedules get complicated. You could have multiple tables for each type of recurring period (annual, biannual, daily, monthly, weekly, etc...) or punt and use jsonb to store the spec. The spec might be { "period": "weekly", "days": [1,2,3,4,5] } for every weekday. Reference the iCal spec and good calendaring software for what sorts of repeat events you'd want and other attributes.
jsonb is not a panacea, but this table is only for reference to generate and update events. It is not used for runtime querying. For that there's a second table.
Then generate individual scheduled events from this, out to a configurable limit.
event_schedules:
id
event_id
recurrent_event_schedule_id
schedule: tztsrange
This table is simple. What event, when, and what recurring schedule it was generated from.
Since you're using Postgres, rather than separate start/end fields, use a timestamp range. These are supported by special operators to determine if a time is inside a range, or if ranges overlap, and so on.
Rails will accept Range types, but it does not directly support the operators. For example, EventSchedule.where("duration #> ?::date", Date.new(2014, 2, 12)) finds all events happening on 2014-02-12.
If you want to edit an individual scheduled event, copy its Event, edit it, and link the EventSchedule to that new Event.
If you want to change the recurring event schedule, select the event_schedules by recurrent_event_schedule_id.
If you want to change the event for all scheduled events, edit the Event linked to the RecurringEventSchedule.
In this way you can define complex recurring events and query the simple concrete events.
Related
I have an entity called “Event“ which has s start and end date properties. I have to show the list of events by grouping them by date in UI. I am using NSFetchedResultsController to fetch and list the events.
Let's assume an event has start date today and end date tomorrow, here I need to show this event on two different dates in UI but I will have only one entry in the database.
I really don’t want to create multiple entries for an event and also I wish to use fetch result controller as it reduces lot manual calculation. Is there any way to solve this?
NSFetchedResultsController does a good job of matching NSManagedObjects to indexPaths for a tableView. However, the mapping is one to one, so any given Event can only appear once in the indexPaths. To achieve what you want, you would need to create a new entity, say EventDate, with a to-many relationship from Event to EventDate. Define a string attribute which reflects whether the date is at the start or end of the event. Then base your FRC on the EventDate entity. Although each EventDate will appear only once, multiple EventDates could relate to a single Event. The inverse relationship from EventDate to Event will enable you to access the details of a single Event from multiple EventDates.
I have an existing live application with an Event model that looks like the following:
class Event < ActiveRecord::Base
has_many :tickets
has_many :orders
has_many :products, through: :orders
has_many :rsvps, through: :orders
end
My problem is that I now need to add in the functionality that will let a user specify that the event needs to be recurring (for which they'll set a schedule). There are a couple of approaches I've thought of as follows:
Have a schedule and parent_event property on the Event model, for which I will trigger a background job after the event is created to create duplicate events in the DB with the parent_event pointing to the main event so that I can aggregate statistics on the main event (like total tickets bought, etc...). This is the easiest route as all of the models references (tickets, rsvps, orders) don't need to be altered.
Create a Schedule model that is a habtm relationship with events, and make tickets, rsvps, etc... belong to that instead. So I'd be creating one event with many Schedules attached to it for recurring events.
Option 1 seems really dirty, especially if users want to delete an event (I'd have to delete all of the duplicates then as well), but it would require the least amount of code-changes. Option 2 seems like it could be the most scalable approach, but I feel like I may be overcomplicating this. Any advice / examples would be appreciated.
I think the first option is the way to go. I have done some tests with Google Calendar and I think their model is similar to the one you are proposing. You can read Google Calendar documentation (I provide some links below). As far as I could read:
A recurring event has many instances
Instances are events
Instances have a link to their parent event (recurringEventId)
When you modify or delete a recurring event, you are asked if you want to modify or delete only this instance, this an the following instances or all instances.
Recurring events have information about the recurrence (as specified in RFC5545). Recurrence information is including in the parent event (it is omitted for single events or instances of recurring events).
An event is an object associated with a specific date or time range. Events are identified by an ID that is unique within a calendar. Besides a start and end date-time, events contain other data such as summary, description, location, status, reminders, attachments, etc.
Types of events: Google Calendar supports single and recurring events:
A single event represents a unique occurrence.
A recurring event defines multiple occurrences.
Instances
A recurring event consists of several instances: its particular occurrences at different times. These instances act as events themselves.
Recurring event modifications can either affect the whole recurring event (and all of its instances), or only individual instances. Instances that differ from their parent recurring event are called exceptions. For example, an attendee can be invited to just one instance of a recurring event.
Official information about Google Calendar:
https://developers.google.com/google-apps/calendar/concepts/events-calendars
https://developers.google.com/google-apps/calendar/v3/reference/events
I am trying to make a Calendar app. I want to persist the events into Core Data. But the situation is like this, if I want to a recurring event like "every day at 6 AM wake me up". How to define this event model in Core Data? And should I calculate the events from now on to like next year, and save all these events back into Core Data, or I just save one event to Core Data but have a recurrence rule set it to like "every day at 6 AM". Is there any tutorial online like this I can learn about?
That depends on how big the application is (how many features does it have).
If it doesn't have much features, then your second idea is the way to go - Just have a flag in your core-data entity of "Recurring" to set it's a recurring event. Load all events from your core-data model and then filter the
recurring events from the normal ones. Now, set up local/remote
notifications based on your logic.
Otherwise, You can create it more abstract with an abstract entity "Event" and some entities that inherit from it like: "Normal Event", "Recurring Event" - Each fulfilling its own logic. That way, when you load the entities from your core-data model, you just fetch every "Event" entity (which will be both normal and recurring) and apply any logic you need.
You can explore some of the projects here to see some calendar application references.
What would be the best way to incorporate a loan amortization schedule in my rails app? Is it possible? Is ruby on rails even a good way to implement something like that? I have built them in excel a few times before, but just can't picture how to do it in rails.
This all depends on the actions your users will need to perform on/with the schedule.
If your goal is simply displaying the schedule, there's no need to persist the entire array of dates/payments/etc. Simply store a start/end date, payment interval, loan amount, interest rate and the payment amount. It isn't heavy work to construct the actual schedule given this information.
If your users should be able to annotate specific items within the schedule, then consider which properties of each item would make good unique identifiers (hint: loan + item date). From there, your models should flesh out easily:
class ScheduleItem
{
date dueDate;
float paymentAmount;
string annotations;
bool isPaid;
...
}
class Schedule
{
int loanId;
date startDate;
date endDate;
...
}
If you do decide you need models (to persist or just to generate views) representing the schedule start with the simplest implementation possible and expand from there. You're most likely having trouble getting started because you're trying to incorporate every variable from the start. Keep it simple. Get things rolling.
I am considering developing an application using Ruby on Rails that is a planner of sorts. I would like to give a user the ability to see a list of days, click a particular day, and then add things like: Meals, Expenses, Events, Todos, and Exercises. Really I am doing this for me and my growing family.
I am curious with how best to implement this. I can certainly see that Meals, Expenses, etc. need to belong_to :user but I am curious how to implement the belongs_to :day or something like that. Using the created_at or updated_at wouldn't necessarily allow me to provide views for future dates.
I can see how if I created a Days table and then added days through a time and date field that this would work but seems a little strange to ask people to create the actual days.
Or perhaps instead of that I could just create links to variables that search for #today, #tomorrow, but that would get messy.
I have browsed for gems/plugins but can't find one that works. Ideally a person would be able.
Anyone have any thoughts on how to implement something like this?
There are a number of existing Rails calendars, such as http://github.com/elevation/event_calendar or http://github.com/topfunky/calendar%5Fhelper.
However, to answer your specific question about dates: I don't think there's any need to have Day as a model; simply give each event a start date and time, and an end date and time. Remember that Ruby makes it easy to search based on ranges, so "give me all of the events next week" is a cinch if each event has dates and times associated with it.
I'll give it a shot...
Two tables; users and events. A user has many events and an event belongs to a user. Meal, Expenses, etc. are various types of Event. Within events, you can have fields for start and end time of the events. If needed (lets say an events last over multiple days), you could remove the day/time when events occurs into it's own table.
This way, when displaying the calendar for a user, you can find all the events for that date. If none are found, then display nothing.
What do you think?
I would add a model called "Events" and have a properties of the model to represent start date/time, end date/time. I do not think you need a Days model, you can generate your calendar view from the Date class built into ruby.
I have done same kind of project for the Event management in training institute. At there I used event_calender plug in with rails. (enter link description here)
In there we just need to create Event model only. Then we can easily work with that.