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.