On 9/19/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> It sounds like you're talking about making the m2m table a 3 foreign
> key affair (with the third foreign key referencing the intermediate
> data) rather than just adding 2 foreign keys (from and to) to the
> intermediate model. I'd be inclined to treat the 'Role' table as-is,
> but the fact that it is referenced in a 'through' attribute means that
> it gets 2 foreign keys automagically added. The approach you are
> proposing will require a lot more table joins to get anything done,
> and I'm not sure I see the benefit.
I have no need for a third foreign key anywhere. Indeed, the Role
would simply have 2 additional foreign keys added when assigned to a
'through' attribute. When I mentioned the three items going to the
signal, I only included the intermediate object so the signal handler
could access the intermediate data. Doing so wouldn't require a third
foreign key. After all, I'd like to build it in such a way that it
could be used behind the scenes for even the simple case, where
existing code would Just Work, unmodified.
> Also - I'm not sure I understand why you're getting so attached to
> signals. Signals should only be required if there isn't a clear
> connection between the stimulating action and the response. In the
> case of m2m, when you add a relationship, you should have a handle to
> the two models being related (and in the case of m2m intermediates,
> the intermediate model) - there isn't anything ambiguous about the
> target of the action. Why is a signal required?
To be honest, I'm not a fan of signals for this. You're right, it's
not really a straightforward approach, and it has other problems, such
as not being able to prevent an addition/removal, only reacting to it.
I'm just having a problem figuring out how to handle the
add()/remove() cases. Here's the problem I'm running into.
Consider a situation (as I need) where you have user-created groups
(in my case, called Guilds), and you need to limit how many groups a
user can be a member of. This example isn't a proposal, but it should
demonstrate at least what I'm hoping to accomplish.
from django.contrib.auth.models import User
class Membership(models.Model):
def add(self, user, guild):
if user.guild_set.count() > 3:
raise Exception, "Maximum guild membership has been reached."
super(Membership, self).add(user, guild)
class Guild(models.Model):
name = models.CharField(maxlength=255)
members = models.ManyToManyField(User, through=Membership)
The real problem is in calling add(). The function definition needs to
be able to know the User from the Guild, while the internals need to
be able to call add() in such a way that the User and Guild are always
in the same position.
Looking at it again, would it be possible to munge the model names
into argument names and pass them as **kwargs? So the internals would
take "User" and "Guild" and pass them as "user" and "guild". A
multi-word name like "TelevisionShow" would become "television_show"?
I don't know, that seems a bit too magical for my taste, but it seems
like it's either a little bit of magic or a lot of explicit
declarations. I suppose I'm willing to settle for a little bit of
magic.
Thoughts?
-Gul
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
