WIP: workshops/models.py: Add Host and EventHost models

[wking]

To distinguish between the Site (a physical location, e.g. TGAG, the
Genome Analysis Centre, Norwich Research Park, Colney, Norwich,
Norfolk, United Kingdom, 52.621699 N, 1.21888 E) and the Host
(possibly a diffuse entity, e.g. ELIXIR, the European life-sciences
Infrastructure for biological Information). A diffuse host can have
many sites, and a particular workshop can have many collaborating
hosts. The many-to-many relationship (one host can support several
events, and one event may have several hosts) is not layed out
explicitly in our charter, but we have:

Hosting a workshop means providing space for it, supporting travel
costs for instructors (if applicable), etc.

and its conceivable that one host could provide space while others
could fund instructor travel, etc. I've added the free-form
EventHost.notes to keep track of this, and I expect it will have
values like "providing the site", "funding travel for instructor Alice
Bobsdaughter", "providing coffee and snacks for the first day of the
event", etc. If a single host provides for the whole event, I'd just
leave this field blank.

This pull request is currently a work-in-progress while we work out
the models, after which I'll go through and fill in the migrations,
view changes, etc. I'll remove the WIP note in the summary once I
think it's ready for merging.

Fixes #5 and #6.

[wking]

I think Sites and Hosts should have contact information, but I'm not sure if that should be a link to a Person (or several Person instances?) or just Site.email. I'm leaning towards Site.person, because it's nice to be able to configure the name (even if it's just ELIXER/SWC Liason <info@elixir-europe.org>). We might also need to support multiple contacts per site/host via something like:

class SiteContact(models.Model):
    site = models.ForeignKey(Site)
    person = models.ForeignKey(Person)
    role = models.CharField(max_length=STR_LONG)

(with a similar HostContact model), with entries like (<Host ELIXER>, <Person Alice Bobsdaughter>, "SWC liason for the UK branch").

[gvwilson]

1. I think host-to-site is one-to-many - we haven't had anything that would need many-to-many.
2. So far, we've been tracking contact people for sites in the 'notes' field because it's often complicated (so-and-so for travel, someone else for payment, a third person is hosting a talk by one of the instructors, etc.).
3. The general 'tag' mechanism for labeling organizations so that we can identify ones that are organizers (SSI, MSL, etc.) is a good one - can that be put in a separate PR and we can merge it right away?

[wking]

On Tue, Jan 06, 2015 at 06:03:18PM -0800, Greg Wilson wrote:

1. I think host-to-site is one-to-many - we haven't had anything
   that would need many-to-many.

You're never going to have multiple sponsors for a workshop? I think
the multi-host scenario I outline in my inital post seems pretty
reasonable.

1. So far, we've been tracking contact people for sites in the
   'notes' field because it's often complicated (so-and-so for
   travel, someone else for payment, a third person is hosting a
   talk by one of the instructors, etc.).

Works for me.

1. The general 'tag' mechanism for labeling organizations so that we
   can identify ones that are organizers (SSI, MSL, etc.) is a good
   one - can that be put in a separate PR and we can merge it right
   away?

Done in #126.

[gvwilson]

I don't think we're going to incorporate this any time soon - permission to close?

[wking]

On Wed, May 27, 2015 at 10:39:09AM -0700, Greg Wilson wrote:

I don't think we're going to incorporate this any time soon -
permission to close?

@pbanaszkiewicz added this to v0.4 yesterday.

[pbanaszkiewicz]

I've scheduled it for discussion in v0.4 window, but I didn't go into the code.

[gvwilson]

Close as stale?

[pbanaszkiewicz]

Can we discuss this after we release v0.3?

[wking]

On Mon, Jun 01, 2015 at 10:52:09AM -0700, Greg Wilson wrote:

Close as stale?

I think this is still a good idea. If it doesn't get into v0.4 as
scheduled, I'll likely have time to rebase it in the next few weeks
(but I need to finish rebasing #110 first).

[wking]

We can address some of the modeling issues before I get around to
rebasing this though. Outstanding questions from earlier PR comments:

• How do we handle contact information for Sites and Hosts 1?
• Should the Event/Host relationship be many-to-many (as it is in the
  current PR with the EventHost table) or one-to-one (see the initial
  comment and [2,3])?

[gvwilson]

I understand that this makes sense in DB terms; I doubt the admins using the system will ever input the information (and will regard the complication of the common case as unwelcome).

[wking]

On Mon, Jun 01, 2015 at 11:09:09AM -0700, Greg Wilson wrote:

I understand that this makes sense in DB terms; I doubt the admins
using the system will ever input the information (and will regard
the complication of the common case as unwelcome).

Which information? Just the distinction between sites and hosts? How
do we handle ELIXER now? How do we record who is providing space,
supporting travel costs for instructors, etc.? Actually, looking over
the charter again 1, I see that we define “hosting” and use that
definition to separate “internal” and “external” events, but none of
those distinctions are important for the membership categories 2.
Requirements for members and the SCF only revolve around
coordinating workshops. The only place I can find where the site/host
distinction may be important is for is 1.b 2:

if the Partner is a distributed collaboration, no more than one third
of the workshops may be at any single site.

in which case we'd need to distinguish between that parter's (Host's)
Site A, Site B, etc.

[pbanaszkiewicz]

Okay, @wking and @gvwilson, what do you think of this compromis:

1. Rename Site to Host
2. Make Host.country not required
3. Limit Event.site to hosts with non-null host.country
4. Keep Event.organizer the same as before, ie. not limited

[wking]

On Fri, Jun 12, 2015 at 04:37:21AM -0700, Piotr Banaszkiewicz wrote:

1. Rename Site to Host
2. Make Host.country not required
3. Limit Event.site to hosts with non-null host.country
4. Keep Event.organizer the same as before, ie. not limited

Hmm, so “keep the current conflation between Sites and Hosts, but add
constraints to individual ForeignKeys to apply the appropriate checks
for each underlying idea”? I'd rather have the database model reflect
our mental model ;). I'm still not clear on why having two database
models would increase admin workloads 1, but how about this:

1. Rename Site to Host and migrate.

2. Add the new Site model (from this PR?) and migrate.

3. For each Host that's currently the target of an Event.site link,
   clone as much Host information as possible into the new Site
   instance:

   Host.fullname → Site.name
   Host.country → Site.county
   Host.notes → Site.notes

   Use sentinel values for the other fields (Site.airport, .latitude,
   and .longitude).

4. Change the Event.site type to point back to Site (we'd pointed it
   at Host in (1)).

5. Add a migration for (4) that, for each event with a site,
   replaces the previously-linked Host with a link to the Site cloned
   from that Host in (3).

After the migration, I expect Host data to be pretty stable and grow
slowly, I don't see much maintenance burden on the admin side. If we
want to auto-select organizer Hosts based on previous Hosts for a
given Site, that would be possible with a JSON endpoint.

This still doesn't address the “do we want to track multiple
organizers?” issue 2.

[pbanaszkiewicz]

Ref #5 (comment)

[pbanaszkiewicz]

Closing since we opted for #440 implementation instead.