Issue of hierarchical ownership/watching.

A user wants to watch over a whole Site, thus he wants to watch over all milestones as well as tickets.
Get notified on modifications, as well as new entries.

Using the star model, we can only point a single user and a single object.

The flaw there is that if we introduce hierarchical behavior, there is no clear solution to the following problems:

1. If adding a Star to a parent, should it add stars for the children?
2. Saying that is does, what about when you remove the star?
3. Either you remove all or you remove none, either way it is very destructive behavior.
4. Say that you don't add stars for the children.
5. You can walk up the tree when you need to find change-watchers for notifications, however it becomes very costly to create a list of objects that a user is watching, as you need to walk the tree for each item. Or aggregate the trees of all stars.

This aggregate behavior might be good for limiting the viewing scope of a user, if we are using a star-like model for viewing access.



One possible solution is to extend the Stars to contain a second GFKS that is the 'parent' object that is the source of the watching.

This solves issue 1.
When staring a parent Star, you create the following rows:

user    stared-obj    star-source
Joe        parent        None
Joe        child-1        parent
Joe        child-2        parent
Joe        child-3        parent

If Joe already has a ticket on child-2, it doesn't matter, we still write the row.

user    stared-obj    star-source
Joe        parent        None
Joe        child-1        parent
Joe        child-2        parent
Joe        child-3        parent
Joe        child-2        None

There can be 3 possible states for a stared object.

Not stared        ☆     No user<>obj row
Stared            ★    a user<>obj<>None row
inheriting Star    ⛤    a user<>obj<>notNone row without a user<>obj<>None row

Issue-2 is resolved as we just delete all rows where parrent is in the stared-obj or star-source row.
Issue-3 is resolved since it's non-destructive.

Issue-4,5 are resolved since to find change-watchers we just find all user<>obj rows, and aggregate for user. And to find all watched objs, we do the same procedure.