Michael, I think I understand what you're getting at, given your comment referring to the "unnecessary table and associated join". I think you want to be able to say "ManyToOneField" in Place and have it reach back into the Photo model and insert a NULLable "place_id" column. That's problematic for several reasons:
1. The Photo model is no longer self-contained. You can't look at the model and infer the table layout. So, for example, you can't just syncdb on the Photo model's application and get the table you want. Without knowledge of other applications (potentially in other projects!) you don't know what the table will look like. 2. It produces inelegant tables at best (I'm too lazy to confirm whether it actually violates any normalization rules). If you have many models referring to Photo in this way, it will have equally many columns, most of which will be NULL in any case. If you want it to work this way, I think it is best that you are explicit about the presence of the foreign keys and code ForeignKey(x, null=True) within the Photo model. But if you want the "directionality" to go the way you indicate, I do think it is correct and more elegant to have the intermediate join table. -- Scott On Tue, May 13, 2008 at 3:41 PM, Michael Burton <[EMAIL PROTECTED]> wrote: > > Sure. OOM relationships can typically be broken down along two > dimensions: cardinality and directionality. > > cardinality: DIRECTIONALITY > ---------------------------------- > One-to-one: ONE-WAY, BI-WAY > One-to-many: ONE-WAY, BI-WAY > Many-to-many: ONE-WAY, BI-WAY > > > The cardinality is pretty obvious, it's just one-to-one, one-to-many, > or many-to-many, as we'd all expect. Django assumes that all > relationships are bi-directional, meaning that if there's a > relationship between A and B then you can access that relationship > from A and you can also access it from B. > > However, in some cases (like the one I originally asked the question > about), it's useful to have a one-way relationship, such that you can > access B from A, but not the other way around. In this case, the > directionality would be one-way. > > I'm making up all the terminology here, but hopefully the idea comes > across. Django assumes bidirectionality[1], but it would be nice to > be able to make uni-directional relationships for those cases, like > Photo, where the photo can be owned by multiple different models in a > one-to-many way. > > To keep the models clean my plan is to use your many-to-many > suggestion, but it does result in an unnecessary table and associated > join, which is a bummer but tolerable. > > Thanks again, > Mike > > [1] From > http://www.djangoproject.com/documentation/db-api/#how-are-the-backward-relationships-possible > : > "Other object-relational mappers require you to define relationships > on both sides. The Django developers believe this is a violation of > the DRY (Don't Repeat Yourself) principle, so Django only requires you > to define the relationship on one end." > > > On May 13, 12:03 pm, "Scott Moonen" <[EMAIL PROTECTED]> wrote: > > Michael, can you elaborate on what you mean by "forcing bi-directional > > relationships"? > > > > The ManyToManyField approach really is, I think, the "right" way to do > it. > > If you think about it, a hypothetical ManyToOneField in your case would > work > > almost exactly like the ManyToManyField. The join table would be > structured > > exactly the same, except it would have an additional UNIQUE(photo_id) > > qualifier. > > > > -- Scott > > > > > > > > On Tue, May 13, 2008 at 2:56 PM, Michael Burton <[EMAIL PROTECTED]> > wrote: > > > > > Thanks much, Scott. They both seem a bit hacky, but it gives me > > > something to work with anyway. > > > > > I recognize the motivation for forcing bi-directional relationships in > > > Django was done to keep things DRY[1], but does anyone know if there's > > > been any discussion about maybe relaxing this constraint? Seems a > > > little restrictive, and I don't think most other web frameworks go > > > this route for that very reason... > > > > > Mike > > > > > [1] > > >http://www.djangoproject.com/documentation/db-api/#how-are-the-backwa. > .. > > > > > On May 13, 11:32 am, "Scott Moonen" <[EMAIL PROTECTED]> wrote: > > > > Michael, you have two alternatives: > > > > > > 1. Create ManyToManyField fields in the UserProfile and Place > models, > > > > pointing to Photo. "ManyToManyField" may seem a bit odd since > you > > > really > > > > have a many-to-one relation, but it will work as you expect, > creating > > > a join > > > > table connecting each pair of models. > > > > 2. Create two ForeignKey fields in Photo, one to UserProfile and > one > > > > to Photo, with null=True. Yes, this is a bit ugly. :) > > > > > > -- Scott > > > > > > On Tue, May 13, 2008 at 2:24 PM, Michael Burton <[EMAIL PROTECTED]> > > > wrote: > > > > > > > I have some Places and I have some Users in my database. I'd like > to > > > > > be able to associate some Photos with each. > > > > > > > class Photo(models.Model): > > > > > # a model that represents a photo > > > > > > > class UserProfile(models.Model): > > > > > # has a list of Photos > > > > > > > class Place(models.Model): > > > > > # has a list of Photos > > > > > > > Normally, if i were using another ORM framework, I would make my > Place > > > > > have a list of photos, and I'd make my UserProfile have a list of > > > > > photos, and I'd leave my Photo model alone. However, the Django > way > > > > > of doing things requires that I put a ForeignKey into my Photo > model > > > > > to establish the one-to-many. > > > > > > > The problem is, sometimes Photo's ForeignKey will point to a > > > > > UserProfile and sometimes to an Place. How can I have both my > > > > > UserProfile and Place models point to Photos? > > > > > > > Thanks in advance, > > > > > Mike > > > > > > --http://scott.andstuff.org/|http://truthadorned.org/<http://scott.andstuff.org/%7Chttp://truthadorned.org/> > <http://scott.andstuff.org/%7Chttp://truthadorned.org/> > > > > --http://scott.andstuff.org/|http://truthadorned.org/<http://scott.andstuff.org/%7Chttp://truthadorned.org/> > > > -- http://scott.andstuff.org/ | http://truthadorned.org/ --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
