On 26/04/2016 9:41 PM, Bruce Whealton wrote:
Mike,
         So, I tried your idea for reorganizing the models, and
just removed Organization and instead setup
ContactOrOrganization as a class. Â
It seemed to work ok, in terms of migrating fine. Â However, the
database now lacks a ContactsOrOrganizationÂ
table. Â
Oops, my mistake, it does have a table now for that model. Â I wonder if
I need a ForeignKey field in the ContactsOrOrganization table?

Bruce

I thought I'd better try it myself and this models.py in an app called "contact" works for me. I'm using Python 3.4 and Django 1.8.12 on Windows 8.1 with Postgres 9.3 on localhost.

Because I kept doing typos I changed that ridiculously long name to Entity. Also, mindful of your requirement to have different types of entities namely people and organisations, I did a a Role model to carry that information. In fact I could have done a choices= attribute on Entity but I might use this myself and I would prefer the 1:n approach because an entity could be more than just one sort of entity.

Anyway, once the initial migration for the following models.py is run and the tables exist it is easy to flesh out any of the models with more fields and/or other related tables and rely on migrate to roll out the changes.

from django.db import models

class Role(models.Model):

    name = models.CharField(max_length=32)

    class Meta:
        verbose_name = 'Entity type'
        verbose_name_plural = 'Entity types'

    def __str__(self):
        return "{0}".format(self.name)


class Entity(models.Model):

    connections = models.ManyToManyField("self",
        blank=True,
        symmetrical=False,
        through="Entity_Connections")

    role = models.ForeignKey("role")

    name = models.CharField(max_length=128)

    comment = models.TextField(null=True, blank=True)

    class Meta:
        verbose_name = 'Entity'
        verbose_name_plural = 'Entities'

    def __str__(self):
        return "{0} {{1})".format(self.name, self.role)

class Entity_Connections(models.Model):

    from_entity = models.ForeignKey("entity",
        related_name="from_entity")

    to_entity = models.ForeignKey("entity", blank=True,
        related_name="to_entity")

    class Meta:
        verbose_name = 'Connection'
        verbose_name_plural = 'Connnections'


Good luck

Mike


Bruce


Anyway, I will try to remove the ManyToMany statement from the
Connections Model. Â
I would then have one Contact or Organization maps to many Connection
types. Â

On Sunday, April 24, 2016 at 1:13:16 AM UTC-4, Mike Dewhirst wrote:


    I think you should rethink your Contact and Organization classes and
    see
    if you can eliminate one or the other. A single table for both would
    simplify the problem because the Connection class can implement as many
    connections as you like.

    For example ...

    class ContactOrOrganization(etc):
    Â  Â  Â various detail fields ...

    class Connection(etc):
    Â  Â  Â organization = ForeignKey("ContactOrOrganization",
    Â  Â  Â  Â  Â related_name="organization")
    Â  Â  Â contact = ForeignKey("ContactOrOrganization",
    Â  Â  Â  Â  Â related_name="contact")

    Just because I used related_name that way means nothing. You can
    connect
    contacts together or organizations together. Also, you can add other
    fields to Connection with which to describe the relationship.

    Mike

    > I wanted to use the Organization as a foreign key on the Contact
    model.
    > Â I could have more than one contact from
    > an Organization. Â The Connection model is inspired by the Google
    Plus
    > idea of "Circles" - e.g. friends,
    > family, following, etc. Â  So, this would be a many-to-many
    relationship. Â
    >
    > My problems are (1) I cannot create connections without specifying a
    > contact. Â
    > (2) If I was adding a contact using the admin interface, how do I
    allow
    > no value for that foreign field
    > or allow for some kind of ajax type of text completion? Â If a
    person is
    > family or friend, I may not need
    > to list an Organization for them.
    > (3) I would like to support multiple connection types - e.g.
    following,
    > employer, etc.
    >
    > So, here is my apps models.py file:
    > Â >>>>
    >
    > from django.db import models
    >
    >

--
You received this message because you are subscribed to the Google
Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to django-users+unsubscr...@googlegroups.com
<mailto:django-users+unsubscr...@googlegroups.com>.
To post to this group, send email to django-users@googlegroups.com
<mailto:django-users@googlegroups.com>.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/32dfa22a-0a55-4fdf-9da0-73152b1223aa%40googlegroups.com
<https://groups.google.com/d/msgid/django-users/32dfa22a-0a55-4fdf-9da0-73152b1223aa%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/9dd54be9-440a-6ecc-76bb-0a53ffa96cd5%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.

Reply via email to