Yes, I think that does make sense. Thank you!
While pondering this, I also came up with a third option, which is to
make the alias data part of the Account model, and allow Accounts to
have parent accounts; then only accounts with no parents are permitted
to be assigned to users. (Also prohibiting accounts with parents from
having children to prevent deeply nested trees.) I suppose the same
could be done with the Aliases having parents / children instead of
the accounts, so as not to have to duplicate other account data.
On Aug 18, 6:30 pm, Joshua Russo <josh.r.ru...@gmail.com> wrote:
> On Tue, Aug 18, 2009 at 8:26 PM, ringemup <ringe...@gmail.com> wrote:
>
> > I have accounts that can have multiple aliases, but each account must
> > have a primary alias. I can think of two ways to institute this, but
> > they both have problems:
>
> > 1) reference the primary alias from the account:
>
> > class Account(models.Model):
> > ...
> > primary_alias = models.OneToOneField('Alias',
> > related_name='accout_if_primary')
>
> > class Alias(models.Model):
> > name = models.CharField(max_length=50, primary_key=True)
> > account = models.ForeignKey(Account)
>
> > The trouble with this approach is that basically you can't create an
> > account without an alias, and you can't create an alias without an
> > account because of what amount to circular references, so you
> > essentially can't add any data.
>
> > 2) Assign primary status to the alias:
>
> > class Account(models.Model):
> > ...
>
> > class Alias(models.Model):
> > name = models.CharField(max_length=50, primary_key=True)
> > account = models.ForeignKey(Account)
> > is_primary = models.BooleanField(default=False)
>
> > The trouble here is that it is a real pain to enforce that each
> > account has a primary alias (in fact you have to initially create an
> > account with no aliases and then create aliases and add them to it).
> > Additionally, enforcing a limit on the number of aliases is
> > problematic. Finally, even if you do enforce these constraints
> > programmatically, it doesn't seem to be feasible to relay error
> > messages to contrib.admin.
>
> > Has anyone else encountered this design problem, and how did you go
> > about addressing it?
>
> I have experienced this situation a couple of times and I would recommend
> the second option you discussed. Circular referenced like your first option
> can become very problematic and are not recommended from a database design
> perspective.
>
> What I would recommend is to create an Alias record automatically when a new
> Account is created. You can do this in the save of the Account model or with
> signals.http://docs.djangoproject.com/en/dev/ref/models/instances/http://docs.djangoproject.com/en/dev/ref/signals/
>
> Then in the save of the Alias you can manage the primary flag. I just check
> to see if the current record being saved has primary set, if so then I reset
> all others for (in your case) the account to not primary. The only other
> case is if the current alias isn't set as primary, check to see if there are
> any primary aliases yet and if not automatically set the current one as
> primary.
>
> Ya, it's a little tricky but it's worth not having the headache of the
> circular reference.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
