How do I tell django-extensions' shell_plus what models I want to autoload?
In the past whenever shell_plus wasn't autoloading my models it was normally because there was an error in the models and it was causing the autoloading to fail.
If you open shell plus and then try to manually load your modules one at a time what happens?
from app.models import ModelName
Another thing to try is to turn off all of the apps except for the default django apps in the settings file, and see if they autoload just fine. If they do, then slowly add more and more apps, one at a time, until it stops working, then you can find out which model is having issues. Once you know which model is having issues, it will make it easier to find out what is going on.
The most common error I had was a cyclical dependency between two different models (this model depends on that model, but it wasn't loaded yet, and vice versa).
Hope that helps.
shell_plus – An enhanced version of
the Django shell. It will autoload all
your models making it easy to work
with the ORM right away.
Quote from django-extensions github wiki located https://github.com/django-extensions/django-extensions/wiki/Current-Command-Extensions
Don't believe its actually changeable its designed to quickly autoload ALL models.
I've made a new patch for the shell_plus extension that makes it possible to ignore some models. Waiting for https://github.com/django-extensions/django-extensions/pull/99 to get accepted.
according to the code. shell_plus always loading all your models.
By default shell_plus always loads all your models.
Thanks to #xeor you can use the option SHELL_PLUS_DONT_LOAD in your settings to skip some of your models.
You can also configure aliases to your models to avoid names collisions.
More details:
http://django-extensions.readthedocs.org/en/latest/shell_plus.html?highlight=shell_plus#configuration
Related
I read the documents, but could not understand how removing the need of models.py will improve the system.
The benefits are listed in bullet form here. You can see that not requiring models.py is just one of stated benefits of the new approach.
Applications can run code at startup, before Django does anything else, with the ready() method of their configuration.
Application labels are assigned correctly to models even when they’re defined outside of models.py. You don’t have to set app_label explicitly any more.
It is possible to omit models.py entirely if an application doesn’t have any models.
Applications can be relabeled with the label attribute of application configurations, to work around label conflicts.
The name of applications can be customized in the admin with the verbose_name of application configurations.
The admin automatically calls autodiscover() when Django starts. You can consequently remove this line from your URLconf.
Django imports all application configurations and models as soon as it starts, through a deterministic and straightforward process. This should make it easier to diagnose import issues such as import loops.
In addition, various bugs having to do with app loading were fixed under the rubric of app-loading refactor. For example, it used to be that some parts of the system looked at the INSTALLED_APPS from front-to-back and others back-to-front. Now the order is consistent throughout the system.
As for models.py, it doesn't make sense to use that to mark applications when it's not necessary to have models to be an application (for example, a reusable app can just have templates, say, or management commands). You used to have to include an empty models.py file; now you can leave it out entirely.
From the Django docs:
How are the backward relationships possible?
Other object-relational mappers require you to define relationships on
both sides. The Django developers believe this is a violation of the
DRY (Don’t Repeat Yourself) principle, so Django only requires you to
define the relationship on one end.
But how is this possible, given that a model class doesn’t know which
other model classes are related to it until those other model classes
are loaded?
The answer lies in the INSTALLED_APPS setting. The first time any
model is loaded, Django iterates over every model in INSTALLED_APPS
and creates the backward relationships in memory as needed.
Essentially, one of the functions of INSTALLED_APPS is to tell Django
the entire model domain.
Is there a way to get this ORM model? I am trying to debug some reverse relations that are not automagically created and it would really help to see the whole ORM Django has created.
There is no specific ORM "Model", however there are a few things that may help you.
from django.db.models.loading import get_models
get_models() will return you a list of every registered model, this list is what the mechanism that you are describing loops over.
YourModel._meta.get_all_related_objects_with_model()
This function loops over every field in every registered model and finds and returns any reverse relations to your YourModel.
The Options class from django.db.models.options (YourModel._meta is an Options object) is a good place to look around for this stuff.
Django doesn't "create" an ORM so the question makes no sense. If you want to know what properties the ORM adds to your model classes to support backward relationships then you can
open a django shell, import your models and inspect them
read the source code (hey, it's open source isn't it ?)
if that's not enough, add breakpoints at appropriate places and run the whole thing thru the debugger
I am writing an app in Django which has a few sitewide fixed objects I need to instantiate which, for one reason or another, can't be fixtures.
For example, some (e.g. Permissions) I can't hardcode a PK for because I can't be sure that they'll be loaded in a certain order (and if I use pk=null then I get an IntegrityError if they exist already.)
Others (e.g. Sites) depend on values in settings.py. Edit: These need to run each time the project is deployed, otherwise I could use South's data migrations as per super9's suggestion below.
Since these are Django models, they're not directly related to any of the apps in my project. It would make the most sense to load them in settings.py but that results in a circular import. It works in urls.py but putting the loading code there seems hackish and out-of-place.
I looked into hooking a receiver into post_syncdb as follows:
#receiver(post_syncdb)
def create_groups_and_permissions(sender, **kwargs):
print "Creating groups and permissions"
u_ct = ContentType.objects.get(model="user")
Group.objects.get_or_create(name='Group 1')
Permission.objects.get_or_create(name="Perm 1", codename="perm_1", content_type=u_ct)
However, since I'm using South, per the documentation it only sends post_syncdb when the table is first created. I could call syncdb manually after each time I migrate but would prefer not to.
I am nearly resolved to put them in urls.py or the most closely related app's models.py but thought I'd check here to see if there's an accepted way of loading fixed objects which can't be loaded as fixtures.
Have you checked out data migrations in south yet? http://south.aeracode.org/docs/tutorial/part3.html
Sounds like it might be what you need.
In every generated migration files by South manage.py schemamigration, there usually will be a subclass of the south.v2.SchemaMigration. The class would contain forwards() and backwards() methods and also models attribute. How does South use the models attribute?
This is called ORM freezing.
We also use a human-readable format that’s easy to change; since South relies on the frozen models not only for reacreating the ORM but also for detecting changes, it’s really useful to be able to edit them now and again (and also serves as a valuable debugging tool if you attach failing migrations to a ticket).
http://south.aeracode.org/docs/ormfreezing.html
I am thinking of creating some subclassed Django model fields and distributing them as a package on PyPI. I like to write unit tests for my code (à la TDD), but I'm a bit puzzled as to how I'd write tests for this particular library.
The first thought that came to my mind was to create a Django project that makes use of my subclasses and just use the Django test tools, but that doesn't seem very elegant at all. There's got to be a better way!
Is there a method of somehow bootstrapping Django for this type of thing? I'd appreciate someone pointing me in the right direction. Thanks!
Django itself comes with some tests for field-subclassing; the tests have their own models.py where the custom fields are used. You should get the best impression when you have a look at the actual code yourself!
Addition: To have the models defined in your test package being discovered by django you will have to add your yourapp.test package to INSTALLED_APPS.
Django itself has a built-in mechanism for its own tests to be automatically discovered and added to INSTALLED_APPS.