I Django can 2 apps share 1 model, or 2 apps must define the same model inside. so app1 and app1 can have have same products model inside them for example?
Yes, app1 and app2 can share the same model. You need to import it wherever you want to use it.
Lets say your project structure is like below having 2 apps app1 and app2.
my_project/
manage.py
my_project/
__init__.py
settings.py
urls.py
wsgi.py
app1/
__init__.py
admin.py
migrations/
__init__.py
models.py
tests.py
views.py
app2/
__init__.py
admin.py
migrations/
__init__.py
models.py
tests.py
views.py
Then to use the models defined in app1/models.py in app2, you just need to do:
from app1.models import MyModel # import the model
Just import the model from the app that defines it to the app that is using it.
Related
I have Django 2.1.7
I read Django documentation as well as, this How to use django AppConfig.ready() and this Overriding AppConfig.ready().
Now, the folder/file structure is like this,
my_app
__init__.py
urls.py
sub_app1
migrations
__init__.py
admin.py
apps.py
models.py
...
sub_app2
...
sub_app3
...
and all sub_apps are registered into INSTALLED_APPS of Django settings.py file as my_app.sub_app1 for example. I noticed that when I try to override ready()for sub_app1 w/in sub_app1.apps.py, overriding has no effect.
When I flatten my structure above as
my_app
__init__.py
urls.py
apps.py
overriding of ready works fine.
In other words, it seems that overriding of readyof a sub app w/in sub app's apps.py doesn't work.
Also, whether using default_app_config w/in sub app's __init__.py or my_app.sub_app1.apps.SubApp1Config w/in settings.py INSTALLED_APPS it gives error django.core.exceptions.ImproperlyConfigured: Cannot import 'sub_app1'. Check that 'my_app.sub_app1.apps.SubApp1Config.name' is correct.
Why is this happening?
What is the proper way to say what is my AUTH_USER_MODEL?
I have the following set:
Folder structure:
--- backend
----- api
-------- models
----------- user.py
user.py lies within models folder
in settings.py:
AUTH_USER_MODEL = 'myapp.User'
INSTALLED_APPS = [
'django.contrib.admin',
'django.contrib.auth',
'api',
]
The model:
class User:
class Meta:
app_label = "myapp"
And when I run any manage.py command, for example
python manage.py showmigrations
I get this error:
LookupError: No installed app with label 'myapp'.
The problem solution would be renaming api folder to myapp, which I cannot do due to some restrictions on model names. Or setting AUTH_USER_MODEL to api.User, but this will incur changing all data table names and those must remain the same
Data table names starting with 'myapp_' should not change
Given your folder structure looks like that:
backend
└── api
| ├── __init__.py
| ├── apps.py
| └── models
| ├── __init__.py
| └── user.py
├── manage.py
└── settings.py
then you can create an app config in backend/api/ by creating a file called apps.py inside it. There you can rename your app:
backend/api/apps.py:
from django.apps import AppConfig
class MyAppConfig(AppConfig):
name = 'myapp'
verbose_name = _('My App')
Also you need to add this to the __init__.py inside that folder:
backend/api/__init__.py:
default_app_config = 'api.apps.MyAppConfig'
Also if you want to use myapp.User as your user model you also have to import in in the models module:
backend/api/models/__init__.py:
from .user import User
# or use "from .user import *" to import everything but then make sure you have __all__ defined in user.py
The solution was to change AppConfig.label in class MyAppConfig(AppConfig), so if you update your answer, I will accept it. Changing name ends in nothing, it must be the real name of the module the code sits in, but adding label = 'arbitrary_name' is actually the solution
Using TastyPie (API framework for Django) what is the recommended file structure (or in your opinion).
Have a different resources in each app something like this:
app1
models.py
resources.py
app2
models.py
resources.py
Or create a new app say and have one resource one resource:
app1
app2
apiApp
resources.py
Here is very simple and efficient structure of tastypie api.
Projectname
app1
api
__init__.py
resource.py
models
__init__.py
model1.py
model2.py
migrations
__init__.py
__init__.py
app2
api
models
migrations
__init__.py
common
__init__.py
constant.py
authentication.py
commondata.py
middleware
__init__.pt
cors.py
projectname
__init__.py
settings.py
urls.py
wsgi.py
manage.py
Projectname.wsgi
Creating a new app for just resources does not make sense. I would go with having different resources in each app. Alternatively you can have them in /resource.
I would like to implement a simple queueing service specific to a project. Where should the code go into in the Django directory structure?
Currently the structure is:
sound/
__init__.py
models.py
tests.py
views.py
static
[edit] I am asking where to place the queue service code I created within the direcotry structure above. Should I create a new directory?
Common structures
In Django 1.4+
project_root/
project_name/
media/
static/
some_app/css/app.css # overriding an app css file from project level
css/
project.css
static_root/ # in production using the collectstatic command
templates/some_app/foo.html # overriding some_app at project level
/admin/some_app/some_model/change_list.html
# overriding admin changelist for some_app.models.some_model
settings/
__init__.py
base.py # settings common to all instances of the project
dev.py
staging.py
test.py
prod.py
urls.py
some_app/
static/
css/
app.css
templates/some_app/foo.html
urls.py
views.py
models.py
manage.py
In Django 1.3 and prior
project_root/
some_app/
templates/some_app/foo.html
static/
css/
app.css
urls.py
views.py
models.py
media/
static/
some_app/
css/
app.css # overriding an app css file from project level
css/
project.css
static_root/ (in production)
templates/some_app/foo.html # overriding some_app at project level
/admin/some_app/some_model/change_list.html
# overriding admin changelist for some_app.models.some_model
settings/
__init__.py
base.py # settings common to all instances of the project
dev.py
staging.py
test.py
prod.py
urls.py
manage.py
Alternative approach
project_root/
.gitignore
README.md
docs/
venv/
src/
main/
media/
static/
some_app/css/app.css # overriding an app css file from project level
css/
project.css
static_root/ # in production using the collectstatic command
templates/some_app/foo.html # overriding some_app at project level
/admin/some_app/some_model/change_list.html
# overriding admin changelist for some_app.models.some_model
settings/
__init__.py
base.py
dev.py
staging.py
test.py
prod.py
urls.py
some_app/
static/
css/
app.css
templates/some_app/foo.html
urls.py
views.py
models.py
manage.py
wsgi.py
If you need to use the database, you should add the data models to models.py. For your program I recommend writing it in new python files (e.g. queuing.py) that you would import when and where you want to use it.
You could create another django app just for this as well.
I've just started a new project in django 1.4 and since they've changed the default layout for manage.py and the whole folder hierarchy (see https://docs.djangoproject.com/en/dev/releases/1.4/#updated-default-project-layout-and-manage-py) i cannot decide where should i put my app packages - inside mysite or outside it? What's the best practice? For some reason, startapp command creates the app outside of the mysite package, but this feels somehow wrong.
So, what's the best? This:
manage.py
mysite/
__init__.py
settings.py
urls.py
myapp/
__init__.py
models.py
or this:
manage.py
myapp/
__init__.py
models.py
mysite/
__init__.py
settings.py
urls.py
?
The second way.
manage.py
myapp/
__init__.py
models.py
mysite/
__init__.py
settings.py
urls.py