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
Related
How can I import all models in the settings.py in INSTALLED_APPS? When i`m trying to insert some model there is an error occurred: "no models named app1_model"
-ProjectName
--ProjectName
---models
----__init__.py
----admin.py
----app_1_model
----....
----app_n_model
---templates
---__init__.py
---settings.py
---urls.py
---wsgi.py
--manage.py
^ Structure of project ^
The INSTALLED_APPS is for apps not for models. Models are classes that live within your app, usually in /«app_name»/models.py.
I think you have misunderstood how a Django project is structured. Try working through a tutorial example.
a typical structure:
/«project»/«app_name»/models.py
and in settings:
INSTALLED_APPS = [ ... '«app_name»' ... ]
Your path will contain the base project directory, so you can import your app where you need it.
And to use them:
from «app_name».models import *
Although it is always best not to import *, instead, name the classes you wish to import.
To answer the question in the comment:
If you don't like the idea of storing all your models in one file (even though it is normal to do this), you can create a module called models. To do this, create a directory called /«project»/«app_name»/models, inside it put __init__.py (to declare it as a module) and then create your files inside there. You then need to import your file contents into the module in __init__.py. You should read about Python modules to understand this.
To answer the second comment question:
To view models in admin, you should create an admin file with model admin objects.
And finally:
Please read through the tutorials to ensure you have a thorough understanding of Django. Otherwise you're wasting your own time!
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.
The import statement import the needed parts. but is the "user" class already made when you put that into your installed apps? or do you still need to clarify in models.py in order to make the table in the db? or can someone expand on how to use django users and sessions? I'm looking over the django docs right now and they all just go over how to use the thing once. they never put the code in a syntax where users are going to be the ones using the code through a browser and not you through a python shell.
All installed apps can contribute to the database schema. django.contrib.auth.models contributes, among others, the auth_user table behind the django.contrib.auth.models.User model, therefore you do not have to worry about recreating it unless you have a specific reason to do so.
There's a number of things going on here. As you're aware, Django comes with a number of "contrib" packages that can be used in your app. You "activate" these by putting them into your INSTALLED_APPS.
When you run python manage.py syncdb, Django parse the models.py files of every app in INSTALLED_APPS and creates the associated tables in your database. So, once you have added django.contrib.auth to your INSTALLED_APPS and ran syncdb, the tables for User and Group are there and ready to be used.
Now, if you want to use these models in your other apps, you can import them, as you mention, with something like from django.contrib.auth.models import User. You can then do something like create a ForeignKey, OneToOneField or ManyToManyField on one of your models to the User model. When you do this, no tables are created (with the exception of ManyToManyField; more on that in a bit). The same table is always used for User, just as for any of your own models that you might create relationships between.
ManyToManyFields are slightly different in that an intermediary table is created (often called a "join table") that links both sides of the relationship together. However, this is purely for the purposes of that one particular relationship -- nothing about the actual User table is different or changed in any way.
The point is that one table is created for User and this same table is used to store all Users no matter what context they were created in. You can import User into any and all of your apps, create as many and as varied relationships as you like and nothing really changes as far as User is concerned.
If the table name or something else does not fit in your needs you can always just extend the User model.
from django.contrib.auth.models import User
class Employee(User):
...
Any class extending Model class in models.py contributes to database schema. That means, django search your (and also django core) model.py files and looks for any class that extends Model like:
some models.py
class SomeModel(Model):
...
...
class Otherthing(Model):
...
that is also applies for django core code files. Since all Database tables named using application label and model name, database ables created by django also have that...
For example,
from django.contrib.auth.models import User
If you track file hierarchy django -> contrib -> auth and open models.py file, you will see related model. Ther are also other Model classes in here, like Permission and Group models.
Since these models are under auth application, database tables are auth_user, auth_perission and auth_group
When you run manage.py syncdb command for the first time, django will create these tables...
Think of this:
You create a CMS of some sort, which asks you for an application name and a csv file for that application.
Then it automatically creates that app on the fly, creates the required model.py based on the csv columns, activates the admin page for it and allows only you to have the full permission to this new table via django admin, then it inserts the the app into the url.py and creates the view.py for it as well.
Then all you'd have to do is upload a csv, name your app and whola!, you have an admin page to play with.
Now, is there anyway to create an app or at least a model.py out of a csv file in django or is there any django-app that can do this?
Note: Look beyond (./manage.py inspectdb > models.py)
While this does not involve creating an actual models.py and application, you may want to look into dynamically creating Model classes at runtime. You could have "meta" models that store the information on the dynamic models, and then have your CSV view import the data into those models, create the classes, and register them with the admin. Or something like that.
Creating an actual application directory, with models.py, views.py, and so on, is fairly easy (just create the directory, create the files, and write formatted strings to them based on the CSV data). Editing the project's settings.py and urls.py, and reloading the modules, wouldn't be too difficult either. But, I wouldn't trust automatically generated Django applications without first looking at them.
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.