2

I am working on a Family Tree web app, with Django (which I am new to), and am deciding on how to design a FamilyTree class so that Users can be authorized to view/edit certain Trees only.

As it stands, I have two abstract meta classes: Entity and Relation.

Entity can be a Person, or even a Group or Event. Relation can be Parent, Sibling, Partner, etc.

A Relation has "from" and "to" ForeignKeys, each of which maps to one Entity. Because I liked the abstraction better than this suggestion: Family Tree Data Structure, I decided to only store personal information in the Person subclass of Entity. Relations are accessed through "related name". If code is required, please let me know. I'll need permission to post it.

It seems that there are two general ways to design the FamilyTree class:

  1. ManyToOne relations from a FamilyTree instance to all Entities, or all Relations, or both.

  2. OneToOne relation to a root Entity, or Relation, from which the rest of the Tree is unpacked during a session.

I haven't thought of any downsides to the second method, which seems like it would speed things up.

Pros/Cons for both would be greatly appreciated, as well as your personal choice.

Also:

  • Django-specific implementation thoughts.
  • Maybe assigning permissions based on FamilyTrees alone is not a good idea?

Thanks in advance!

AlexFADev
  • 51
  • 3
  • As far as I understand your structure, the second method would make it harder to look up permissions, if permissions are (only) assigned at the FamilyTree level. To determine the edit permission for a random Person or Event or anything (high up) in the tree, it sounds like you'd need to unravel the complete tree to find out which FamilyTree it belongs to, to find the sought after permission. –  Aug 24 '15 at 01:47
  • Good point. If I cached the Tree after unravelling (at the start of a session), wouldn't that suffice? – AlexFADev Aug 24 '15 at 02:13
  • I don't know; I don't know how easy it is to cache the tree between requests, and it still seems to me you need some structured way to crawl the tree to find the root element and corresponding permissions (I guess there's no direct way to go from a random element in a tree directly to the root element). –  Aug 24 '15 at 02:31
  • I haven't used sessions since I learnt PHP a while ago, but theoretically aren't they supposed to store data for the length of the session? If you unravelled the Tree and listed the Persons, it would be easy to check. Correct me if I'm wrong, but a user would only be able to see/attempt to edit Persons in their respective FamilyTree. So traversing from a random Person back to root (which would be very complicated) seems like an unlikely case. – AlexFADev Aug 24 '15 at 02:46
  • "but a user would only be able to see/attempt to edit Persons in their respective FamilyTree". Not sure. If there's an edit link like `/edit/tree/234/entity/567/`, it's easy to change that manually to `/edit/tree/123/entity/1/` and I'd be editing a completely different Person and tree. You can only prevent that by looking the permissions for that tree (i.e., root entity) in your view. Of course, here the tree is in the URL. But what if the links are like `/edit/entity/567` and `/edit/entity/1`? How do you instantly find out whether the user can edit entity 567 as well as entity 1? –  Aug 24 '15 at 03:09
  • Ya, in that case a complicated traversal algorithm would be needed and any run-time benefits to option 2 would be lost. How about an optional db field that is populated with the owner User when a Person is created during a session? – AlexFADev Aug 24 '15 at 03:22
  • Where would that optional field be attached to? –  Aug 24 '15 at 03:43
  • An attribute of Person – AlexFADev Aug 24 '15 at 15:18
  • That sounds you're almost back to option 1, albeit the field is perhaps temporary. But then I'd go for "explicit is better than implicit." –  Aug 25 '15 at 01:42

0 Answers0