Develop Reference

Directory structure for large django rest framework apps

We've been developing an application using django and django rest framework for a while now and we're reaching a point where our viewsets.py and serializers.py files are getting too large.
Our current structure is very similar to what many posts describe (eg. Large Django application layout) but they only seem to suggest creating new applications as the best route to maintaining manageable directories.
Our current set up is as follows:
project
app1
models.py
serializers.py
viewsets.py
...
app2
models.py
serializers.py
viewsets.py
...
For our use case, our models.py are small and discrete enough that I don't think we need to separate them out into separate applications, but I'm not sure what else we can do.

It's not really clear what you're asking here. Neither Django nor Django Rest Framework accord any special status to the file serializers.py; like views.py, it's just a place where you store things that are imported by other functions. So it's absolutely fine to split that file up in any way you like.
For instance, you could have a serializers package, ie a directory with many Python files in it (including a possibly-empty __init__.py); you could simply have variously named files in the app directory with different serializer classes in them; and so on.

Either split your app into sub application based on usage as mention above.
are you can split it based database like,
app->
tables->
models.py
viewset.py
serializer.py
views->
models.py
viewset.py
serializer.py
procedures->
models.py
viewset.py
serializer.py

In Django, how is the term "app" defined?

In my Django app, I have a lot of code so I have split up my source files and put them into sub-folders, as follows:
myproject/
myapp/
management/
__init__.py
models/
__init__.py
common.py
users.py
matches.py
questionnaires/
demographics/
templates/
__init__.py
models.py
views.py
...
views/
__init__.py
abstract.py
concrete.py
Now I'm confused what to put in INSTALLED_APPS. Is it all the folders containing models? Or all the folders containing source? If i include all child folders, do I also need to include the parent folder? Should this match what's in my my setup.py's packages argument?
Note: I know I could refactor this into multiple apps, but (1) I would like for all this functionality to have a common namespace since it's being redistributed and (2) I am regardless curious for the answer to my question.

Put the directory containing the models.py file, that is your "App". Django uses the models to bind to the database, everything after that is just filler.
The DJango startup is (very slimmed down) as such
manage.py
# The important part
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "path.to.your.settings")
This will define the important pieces, but lets look at the installed
settings.py
INSTALLED_APPS=(
'your.app.name'
)
Which basically states, you'll find my models.py there and some model definitions (they don't have to be defined, but models.py needs to exist)
your/app/name/models.py
class SomeModel(models.Model):
#... model definition ...
pass
Now back to your settings.py
Your source can live ANYWHERE because DJango looks in some very specific locations for certain things, but this is mostly configured in your settings.py
ROOT_URLCONF = 'path.to.urls' # this is the pythonic module path to your `urls.py` file
in your urls.py file you can define a url such as
url(r'^/some/url/def/$', 'some.other.module.handler'),
as long as handler from some.other.module returns a valid HttpResponse object and is on the PYTHONPATH it does not matter where the class lives.
Django has some specifics about management commands, they must live inside your app directory (the same as your model dir) so to define those (if your model.py file is inside a different location) you must put them in your data dir
For example I have a project with the following layout
/app
/data
/commands
some_command.py
models.py
/app
urls.py
settings.py
...other-source-files...
My settings.py simple says load the app data and point to app.url for the url configuration, from that point on it doesn't matter where your source lives (for the most part).
We did this so that our database tables would be named data_sometablename vs app_sometablename (i was not part of this choice, happened long before i joined)

Good Practice: Organizing views.py in Django Apps

I am learning Django. My background is from PHP and Java with experience using Model View Controller frameworks. I have always had a seperate file for each of my views, models, and templates - but the Django tutorial only mentions having one views.py and models.py.
That seems to be okay if you have a small application — what if you would like to organise your views and models by their purpose? For example, a Projects view and a Milestones view. I would hope that you would not have to create another Python package (app) for each view module:
python manage.py startapp projects
python manage.py startapp milestones
I can assume that you can have a milestones.py and a projects.py for your views and models instead of a generic views.py and models.py? Then models can be imported where necessary into the views, and requests routed to specific views?

There is no problem with having multiple files containing views and models.
In fact all you need is module views and module models. In python the module is either file that ends with .py or folder that contains file __init__.py.
The app can look something like:
app_folder
- views
| - __init__.py
| - some_view.py
| - some_other_view.py
- models
| - __init__.py
| - some_model.py
| - some_other_model.py
The models/__init__.py should look similar to code below (for submodules to be looked up by django at all).
from some_model import SomeModel
from some_other_model import SomeOtherModel
The only difference from the common approach is to have app_label defined in models:
class SomeModel(models.Model):
class Meta:
app_label = 'app_folder'
Check out the related doc entry.
Update:
The development version docs say you won't have to define app_label in this case any more starting with 1.7 release.
Afterword:
In fact if you need to do that it usually means your app is too big and you should split it into several apps. Most people who come to django are afraid of having many small apps. The more third party apps you read through the more you realize app should solve one and only one problem. In your example having app milestones seems perfectly legit.

Django tables names

I am refactoring a Django application. Specifically, I have an application with a big models.py file and I am trying to split it into a bunch of small files, like
myapp/
models/
__init__.py
somemodels.py
someothers.py
somemore.py
...
and in models/__init__.py I import all models from all other files so that I do not have to change client code.
The problem is that Django now complains about table names. Table for model Foo used to be myapp_foo, but it seems that Django now looks for a table myapp.models_foo. That is, it seems that it uses as prefix the package where the models are defined instead of their application (of course myapp.models is not registered as a Django application).
I know I could manually set the table name for each and every models, but is there a way to avoid this and tell Django that these models are actually part of myapp?

Use Meta.app_label

Defining models in a top level Django directory

I've noticed that in order for me to define models, I need to do something like:
python manage.py startapp app_name
Is there anyway to avoid this convention and be able to create a models.py directly in the top level site that django-admin.py has created for me? Sometimes I'm building a site that can be put together in literally 15 minutes thanks to Django. I don't see the need for complexity of having an additional app built and a modified settings.py just for a form model or something similar.

Not really. The django admin programs expect app/models.py file names.