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