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
-~----------~----~----~----~------~----~------~--~---
