Adrian Holovaty wrote: > That's the big question -- should the schema be specified in the > settings file or in the model? (Well, I've never used schemas, so > maybe it's not as big of a question as I'm making it out to be. Maybe > it doesn't make sense to put the schema in the model?)
Well here's the thing: I've not been using Django for very long, but I've found the project / app dichotomy both useful and confusing. One of the more confusing aspects of it is how the model table names are constructed with the app name as a prefix. What you often end up with (and I think this is in the tutorial) is something like "poll_polls" and whatnot as table names. This doesn't seem very user-friendly to me. What's worse, you can imagine a large project with several apps such that in the public schema you have a huge number of tables with convoluted names that are difficult to keep track of. If a user is using Django with a database that needs to be accessed from more than one type of service, this is not very pleasant to work with as well. So... It strikes me that one option for this, at least when using Postgres as the database, (and really, why would you use anything else ;) might be to have the actual postgres database hold the entire project, while putting individual apps into their own schema. This alleviates the need to use the app name as a prefix for table names because each app gets its own namespace. Not only would this simplify table names, but it would allow for more freedom in customisation within the database, if you wanted to use stored procedures in a per-app way for example. It would help delineate further the difference betweem apps and projects, as well as provide a more robust logical separation of apps from each other. It seems like it would provide more flexibility overall. What do you think? If the database isn't Postgres, I don't know if the other supported database backends support a similar feature, but if they do it might make sense to implement the same thing for those backends. However for now I'd imagine if I go ahead and make these changes, the behaviour for the other databases should probably stay the same for now. I haven't looked at the code enough to see if this could be done easily without breaking cross-database app support (ie migrating an app from one backend to another without any fancy dancing). Does this seem like a plausible change? If I were to do this, it would be in the magic-removal branch I think? I'll keep familiarising myself with the codebase. > > I forgot to mention this ticket, which has a patch for adding schema support: > > http://code.djangoproject.com/ticket/1051 > > That's on an older version of Django but may give you some ideas. It did give me some ideas, but I really think that schemas should be a per-app setting (which I suppose is more accurately called a per-model setting), not a per-project setting. --Ed --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~----------~----~----~----~------~----~------~--~---
