Well, I'm trying to implement parent / child aliases, but I'm running
into problems with class declaration order because I need to reference
the Alias class from within the Account class as well as referencing
Account from Alias for validation purposes -- and not just in
ForeignKey declarations and such.
Since one will always have to be declared before the other, is there
any way to do this?
On Aug 18, 7:02 pm, Joshua Russo <josh.r.ru...@gmail.com> wrote:
> 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...
>
> > > 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
-~----------~----~----~----~------~----~------~--~---
