On 27-7-2012 6:17, JJ Zolper wrote: > You are probably right to be honest. I might be overdoing it with > seperating things apart. I guess sometimes I'm too efficient! > > Here's some more to chew on though: > > I also want to point out the reason why I am trying to bring one model into > another. > > MadTrak/ > manage.py > MadTrak/ > Artists/ > manage.py > Artists/ > initialize/ > models.py > Fans/ > manage.py > Fans/ > Venues/ > manage.py > Venues/ > GeoDjango/ > manage.py > GeoDjango/ > discover/ > models.py > > As you can see I have 5 projects. MadTrak, Artists, Fans, Venues, > GeoDjango.
Erm, this is a clear example of how to not do things. A project in it's simplest form should correspond to one site, so a virtual host or full fledged server. More complex sites can handle multiple projects, however you should allocate webserver locations to these projects rather then start nesting projects. The documentation should perhaps mention this explicitly, though the fact that the tutorial calls the project 'mysite' should be a hint. Aside from that, I see no reasons that these sub-projects as you call them are in fact projects rather than applications. > The idea here is that the top level MadTrak project handles > everything that has to do with the simple about pages etc. This is probably a lack in the documentation as well, but normally you'd handle stuff like static pages and the home page in the top-level project's inner directory or even bypass django completely by grabbing the urls in the webserver and serving static html. Views for the MadTrak project should be in: MadTrak/ settings.py views.py > The Artists > project has the artist database in it and same for Fans and Venues > respectively. I think you should start by answering /why/ you need separate databases for this. If you have no clear reason, then that's your answer: you don't need separate databases. While a model corresponds to a table, a collection of models /does not/ correspond to a database. In fact, you can run several projects using one single database - it makes no difference to django or the database. Also, the geodjango database drivers are not specifically for spatial databases. And similarly spatial databases can contain tables (and thus django models) that have no geometric fields. So - it is possible to use all your applications in a spatially enabled database with the spatially enabled database driver. -- Melvyn Sopacua -- 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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.