I've considered the address-type-and-foreign-key approach you describe — and implemented it and then backed it out again — but that approach bugs me at a philosophical level. Address is then bound explicitly to Producer and instead of having two addresses each with a specific designation I can have 0-n addresses, one producer with 14 physical addresses, and so on. I understand that I can guard against these situations through validation and overriding save methods and such but object composition seems like such a simple, common, basic need I'm stunned to find it's not easily achievable.
Thanks for the input. On Wednesday, February 13, 2013 2:59:56 PM UTC-6, Adam Mesha wrote: > > Inlines are for related objects, meaning when I have a foreign key from A > to B, on A there is an actual database field that points to B, but on B > there's a virtual (related object) field implemented as a python method. > When you have a foreign key, the way the admin shows that is just to give > you a drop-down list so you can choose the corresponding object in the > other model. > > To go back to the standard example, there is a foreign key pointing from > Book to Author. On the Author admin page you can see and edit all the > books, but on the Book page you just have a drop-down to select the > relevant author. You could think of it as Book extends in a certain sense > Author, so it has a field pointing to its parent. > > What I would probably do in your situation is to get rid of the mailing > address and physical address in your Producer model, and add a type > field(which could be 'mailing' or 'physical' or maybe some more > possibilities) and a producer field foreign key. That would allow for > easily adding more types of addresses, and more than one of a given type. > If it's essential to guarantee that there is exactly one mailing address > and exactly one physical address, I would probably override the relevant > save methods to check for that when objects are saved. > > On Wed, Feb 13, 2013 at 9:25 PM, Ray Hatfield > <[email protected]<javascript:> > > wrote: > >> Hi, >> >> I have a model which requires two addresses: a mailing address and a >> physical address. From an OO perspective it makes sense to have an Address >> class and the Producer to have Address instances as properties, but I can't >> seem to achieve this in django while still being able to edit the addresses >> inline as part of the Producer admin. >> >> I've tried this sort of thing: >> >> class Address( models.Model ): >> street = models.CharField( ... ) >> # city state zip, etc. >> >> class Producer( models.Model ): >> mailing_address = models.OneToOneField( Address, related_name='+' ) >> physical_address = models.OneToOneField( Address, related_name='+' ) >> >> but when I attempt to inline the addresses in the django admin I run into >> trouble. I get errors like: >> >> <class 'producers.models.Address'> has no ForeignKey to <class >> 'producers.models.Producer'> >> >> (This error is true, of course. But I was under the apparently erroneous >> impression that including related_name='+' would prevent django from >> setting up the reverse relationship.) >> >> I realize I could add a foreign key to Address to associate it with a >> specific Producer but this feels backwards to me. An Address shouldn't need >> to know whether it's for a Producer or some other object. It's just an >> address. >> >> I've been banging my head on this for far too long. Advice? >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected]<javascript:> >> . >> Visit this group at http://groups.google.com/group/django-users?hl=en. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > > > -- > Adam Mesha <[email protected] <javascript:>> > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
