Re: Models: Referencing A Model In Another App and Different Project

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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.