On Wed, Jul 22, 2009 at 4:05 PM, dan<danstad...@gmail.com> wrote: > >> >> If a model A has a foreign key on model B, then the table for A >> requires a field to track the relation. However, if model B has a >> "many to one" on A.... table A requires a field. > > sorry, can you clarify that for me? - specifically: "model A has a > foreign key on model B" - which direction do you mean exactly? ... > I think what the original question is asking is, can the definition of > Parent have a "one-to-many" which points to Child? At the database > level there would be no difference: Child would still have the foreign > key field.
You are absolutely correct that the databases would be identical. However, this misses my point. The critical difference is that under option 1, all the information required to create the table for 'parent'. is contained on the Parent model, and all the information required to create the table for 'child' is contained on the Child model. This means that as long as you are able to import the model (i.e. there are no FK references to models that haven't been defined), you can synchronize each model and know that you have all the information that you require in order to complete the synchronization accurately. Under option 2, some of the information required for the child table is contained on the Parent model. Therefore, you can't know for certain if synchronization will be completed, because correctly synchronizing Parent requires that the child either (a) hasn't been synchronized, or (b) can be modified to add the new required column. Why does this matter? This is entirely an issue of the complexity of the synchronization process. Consider one of the most likely use cases: writing a pluggable Django application that tracks the home address of a contrib.auth.User. I start with my project, and I add contrib.auth to INSTALLED_APPS. I synchronize the database and set up admin, media etc. Now, I want to add my pluggable "postal" application. This postal app contains Address model: class Address(Model): street = CharField() city = CharField() zipcode = CharField() users = ManyToOne(User) However, I wouldn't be able to easily add my "postal" pluggable application to INSTALLED_APPS. The auth.User table already exists, so it isn't a simple task to add the extra 'address_id' column that the Address model requires. Resolving this sort of problem requires the ability to perform database schema migrations as part of the synchronization process. Until Django has a migration tool baked in, it isn't really feasible to have a ManyToOne field. Even then - we would need to be able to ensure that migrations would always be able to succeed. For example, what if address was a required field, and I have existing Users? What value for address_id to those users receive as part of the migration? I can sympathize with the intention of the ManyToOne idea. However, adding this apparently simple idea opens up a Pandora's box of problems. Forcing 1-N relations to be defined by ForeignKey (and not by the reverse relation) avoids all these problems. Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---