Tuesday, April 26, 2016

Re: Help with defining Models for ManyToMany and OneToMany relationships...

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+unsubscribe@googlegroups.com
> <mailto:django-users+unsubscribe@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+unsubscribe@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.

No comments:

Post a Comment