On 8/17/06, Hawkeye <[EMAIL PROTECTED]
> wrote:
Could be interpreted as a bug/missing feature, but probably more in the misunderstanding column.
The string quoted form exists to allow you to forward reference a table; i.e.
class Foo(Model):
whiz = models.ForeignKey('Bar')
class Bar(Model):
...
In this example, Bar doesn't exist at the time that the whiz attribute is defined. To allow you to reference a model before it is declared, Django lets you use the string form.
String form references can also be used to refer to models that have already been defined, as long as they exist in the same module. So; if Foo and Bar were in the opposite order, the code would still work.
However, if you are importing a model from an external module, you must use the module form (not string form) to reference it. This is what tripped you up.
Yes, this _could_ be interpreted as a bug - or, more accurately, string references to external modules could be considered a new feature. However, module form referencing is the preferred form of referencing, and the string form only exists to work around ordering problems. As a result, I don't think implementing this feature would be particularly desirable.
However, you _did_ write code assuming that cross-module string references worked - this probably indicates that the documentation needs some work to highlight the limitations of string referencing. I've updated the model API documentation to clarify your situation.
Yours,
Russ Magee %-)
Is this a bug, or was my understanding of quoted ForeignKey values
incorrect?
Could be interpreted as a bug/missing feature, but probably more in the misunderstanding column.
The string quoted form exists to allow you to forward reference a table; i.e.
class Foo(Model):
whiz = models.ForeignKey('Bar')
class Bar(Model):
...
In this example, Bar doesn't exist at the time that the whiz attribute is defined. To allow you to reference a model before it is declared, Django lets you use the string form.
String form references can also be used to refer to models that have already been defined, as long as they exist in the same module. So; if Foo and Bar were in the opposite order, the code would still work.
However, if you are importing a model from an external module, you must use the module form (not string form) to reference it. This is what tripped you up.
Yes, this _could_ be interpreted as a bug - or, more accurately, string references to external modules could be considered a new feature. However, module form referencing is the preferred form of referencing, and the string form only exists to work around ordering problems. As a result, I don't think implementing this feature would be particularly desirable.
However, you _did_ write code assuming that cross-module string references worked - this probably indicates that the documentation needs some work to highlight the limitations of string referencing. I've updated the model API documentation to clarify your situation.
Yours,
Russ Magee %-)
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
