> I could add two foreignkey fields to Address referencing Person and > Company respectively and allow both to be null. Or I could just remove > the Address class and move all address fields into both Person and > Company instead. But both these solutions are IMO uglier.
I'm in the exact same position as you. I use Address for quite a few tables: Orders, Shipments, Customers, People, Warehouses. It only makes sense to have an Address object to hold this information. Especially when an Order has three addresses. I'm not worried about the admin interface so much though, so my first solution was to write my own Manipulator, adding each address field individually. This was a royal pain. I then tried some hacks to get it to automatically happen, but realized that this was futile with the pending newforms changeover. I really think this usage case should be addressed in Django. There is a basic clash between the relational and object-oriented side of the Django ORM. In OOP you expect the parent object to have a pointer to the child, and in relational models it's usually the other way. Django so far has pre-determined that you must follow the relational model, even though it strives to hide that with an OO layer. I posted about this on the dev list and pretty much got ignored. I'm not sure why the devs don't consider this important. -Justin --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
