It may be as simple as creating an intermediary field between Document
and agency called Study. (See the Django docs regarding adding extra
fields to a many-to-many relationship.)

In any event, it is wise not to think of models as objects so much as
stand-ins for DB tables (which is what they are.) So this should be
treated like a schema design problem, not an OO design problem. (Yes I
know models can be inherited abstractly and concretely and I take
advantage of that in my own code, but that can gt you into trouble if
you aren't clear of the limitations that inheriting models imposes.)

If you are unclear on the difference between database schema design
and OO design, then you might want to consider procuring a consultant
to review your schema design in light of your complete set of project
requirements at some time point early in the design process. That
might save you a ton of time and money in the long run.

Rock

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

Reply via email to