Rails - Sep 2006 - Architectural question: one model, different properties

Hi everybody,

I''m currently trying to implement some kind of calendaring system which
manages a multitude of different kinds of events, and I am unsure about
how to represent them properly as models.

All these types of events have some common properties they share, like
a start date, an end date and an owner. However, they all also have one
or more properties distinct to them; for example employee vacations
might require a managers approval and therefor feature an
''is_approved''
flag, while bank holidays need to contain info about their recurrence
pattern, and so on.

What currently eludes me is how to deal with this in an elegant
fashion. While I could of course create either a single
''event'' model
which contains the fields for all these types, or one model for each
event type, neither of those ways feel satisfactory and
''right''.

Maybe I just cannot see the forest for the trees, but how would you
deal with this? Would a base ''event'' model with polymorphic
associations to specialized event type models be a good idea?

Thanks in advance for your thoughts,
Jan


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Hi Jan,

It seems like any solution that requires you to add a new database
table whenever you want to add an event type is a bad idea.

To be honest, unless I had a million different types of event, I''d just
use a single model and set unused fields to null.

You''re going to have to pay somewhere, either in maintaining multiple
database tables, coding some generic container
serialization/deserialization, or having a few null values. The last
seems cheapest to me.

Cheers,
Starr

--
Check out my blog for startups and upstarts: www.thebootstrapnation.com


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Elektroholunder wrote:
> All these types of events have some common properties they share, like
> a start date, an end date and an owner. However, they all also have one
> or more properties distinct to them; for example employee vacations
> might require a managers approval and therefor feature an
''is_approved''
> flag, while bank holidays need to contain info about their recurrence
> pattern, and so on.
You will probably want to look into Rails'' single table inheritance 
(STI) support.

- Roderick

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

That was exactly what I was looking for; so it''s gonna be a single
table with STI.

Thanks a lot to you both!

Cheers,
Jan


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---