Yup, that could work too. Let me know what you end up with.
On Tue, Aug 18, 2009 at 9:58 PM, ringemup <ringe...@gmail.com> wrote:
>
>
> 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
-~----------~----~----~----~------~----~------~--~---
