Double Many to many field (one on each side)

Using Django Using the ORM
1

Hi,
I was using a ‘OrgUser’ model, and an ‘EquipmentModel’ such as :

class Equipment(models.Model):
   ...
   user_in_charge = models.ForeignKey("OrgUser", ...)
   
class OrgUser(models.Model):
   ...
   favorites = models.ManyToManyField(Equipment, blank=True)

But now, happens that I need to have multiple user in charge of equipment per equipment. Thus a many to many relationship.
Is there a way to keep the current structure rather than move the “in_charge” to the User Model ?

I know that it doesn’t change anything as it requires an intermediate table, but for fitting documentation & clarity that would be better.

And i can’t declare both models after the other, or do like I would in C : ensure existence of object B, define A(B), define B(A).

Thanks for help

2

It seems to me that the OrgUser in charge of an Equipment would be an extra field (perhaps a boolean?) in the through table of the many-to-many relationship. See Extra fields on many-to-many relationships for more details.

3

maybe you found this.

class Equipment(models.Model):
   ...
   # user_in_charge = models.ForeignKey("OrgUser", ...)
   
class OrgUser(models.Model):
   ...
   favorites = models.ManyToManyField(Equipment, blank=True)


a = OrgUser.objects.get({# filter})
a.favrites.all() # Equipment QuerySet
b = Equipment.objects.get({# filter})
b.orguser_set.all() # OrgUser Queryset
4

how about following those steps below:

  1. add users_in_charge ManyToManyField to the model Equipment.
class Equipment(models.Model):
   ...
   user_in_charge = models.ForeignKey("OrgUser", ...)
   users_in_charge = models.ManyToManyField("OrgUser")
  1. then create a new migration file to copy data from user_in_charge to users_in_charge.
  2. Lastly, remove the original field user_in_charge
5

That would be a solution but it also means that the information which are different relations would be grouped in a single table. It definitly works but I don’t feel like it’s a clean structure.

Thansk tho.

6

Thanks, was not aware we could quote rather than reference directly other models in MtM relations. (Well shall have tried).

1 Like
7

Model Reference should be QUOTED " as this won’t raise the circular import issue later on.
Please check further here: Django - Circular model import issue - Stack Overflow

The value format should be "app_name.model_class"

8

If you think that that is not a “clean” solution, then I suggest you take some time to read about normalization of data in a relational database, because the other solutions provided here create either replicated data or the possibility of conflicting or inconsistent data.

Be aware that the data defining the relationship between the two models in a ManyToManyField exists in a separate table. So instead of having one separate table to store the relationship and any relationship modifier (e.g. Ownership), you’ve now created two separate tables - one to define a membership and the other to define ownership. Instead of three tables, you now have four.

9

Yes i’m totally aware of this. And as “membership” is something totally different from “ownership” i’d rather have separated data for the clarity of it being two independant objects.
I can’t see how it would replicate data or cause reduced performance to use 4 tables instead of 3 for me it would be the contrary ? Less data per table => smaller products bewteen tables. And I won’t have any use case where i’d need to check both relations as they are fully isolated.

10

I need to clarify for my own understanding what the situation is here.

Specifically, is it a situation where a person is either a “member” or an “owner”, but not both? (You can’t enforce this at the database level with two join tables without using something like a stored procedure.)

Or is it a case where a person can be a “member” and an “owner”? (This is the case where you end up with replicated data.)

Is it the case that if a person is an “owner”, they must be a “member”? (You can’t enforce this at the database level similar to the case above.)

Do you have any potential situation where you might want the disjoint list? (Those who are “member” and not “owner”, or the reverse.) (It is this last situation that is the most clear case of a query that would be less performant than the one join table.)

Or is it the case that the two are truly independant, and that the state of being a “member” has nothing at all to do with being an “owner”? If so, then the concerns identified above probably don’t apply. (Yes, I saw your comment regarding this point in your post, but I’m trying to understand it in the context of the subcases listed above.)

The basic issue is that you’re identifying a relationship between two entities, twice. The only difference between the two is semantics, not structural.

But admittedly, it is an architectural decision, not a technical one. I just don’t like the idea of designing a database around a set of semantics that could possibly change in the future.

11

That’s this one. The clients (don’t know why) decided that owner and members would have two totatlly different websites, using the same data, objects…

To be a bit more precise, a owner has the right to use the member website, but he isn’t an owner anymore at this point (for authorisation check & all). If he does so, he can “subscribe” to an equipment as a member, but that’s totally independant from being the owner of some.

The use cases are for exemple : getting the emails of owner(s). Listing owners, check that you are owning an equipment to allow some edition…
And for the membership, it’s nothing more than a “favorite” toggle on the global equipment list, to display a short list of favorites for the members. It has no impact on rights/auths it’s purely and individual member sorting setting.

I can totally understand this, as furthemore the ownership relations changed from 12M to M2M.

1 Like