On Wed, May 21, 2008 at 12:29 PM, Aidas Bendoraitis <[EMAIL PROTECTED]> wrote: > One use case could be, for example, > the Institution model with title and description fields in project A, > then the Institution model with title, description, and address fields > in project B, > and then the Institution model with title, description, and category > fields in project C.
A whole bunch of people are going to tell you to use inheritance and subclass the base model everywhere. Those people are probably a bit over-eager to treat inheritance as a cure-all; the only time I've ever seen it used in production code, it became a maintenance nightmare (pro tip: World Online has been using Django since, well, as long as it's existed. We have exactly one model that's subclassed, and every time I have to deal with it I wish it wasn't). The way I'd do this is with an application which provides a basic model with the core fields, and then other models in other applications relating to it and adding information as needed. Incidentally, this leads to precisely the same underlying database configuration as inheritance, but is conceptually quite a bit cleaner since you're being explicit about the relationship. Note that this is, for example, how Django's User model works: you relate another model to it with a good old-fashioned foreign key, and there's a nice API for specifying which model represents the "user profile" for a given site. You could emulate that for your own models quite easily. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
