Explore topic-wise InterviewSolutions in .

ModelName.objects.filter(field_name=”TERM”)

ModelName.objects.all()

As the NAME SUGGESTS this file stores the configurations or settings of our Django project, like database configuration, backend engines, middlewares, INSTALLED applications, main URL configurations, STATIC file addresses, templating engines, main URL configurations, security keys, allowed hosts, and MUCH more.

When a view function returns a webpage as HttpResponse instead of a simple string, we use render(). Render function is a shortcut function that lets the developer easily pass the data dictionary with the template. This function then combines the template with a data dictionary via templating engine. FINALLY, this render() returns as HttpResponse with the rendered text, which is the data returned by MODELS. Thus, Django render() bypasses most of the developer’s work and lets him use different template engines.
The basic SYNTAX:
render(request, template_name, context=None, content_type=None, status=None, using=None)
The request is the parameter that generates the response. The template name is the HTML template used, whereas the context is a dict of the data passed on the PAGE from the python. You can also specify the content type, the status of the data you passed, and the render you are returning.

Context is a dictionary mapping template variable NAME GIVEN to Python objects in Django. This is the general name, but you can GIVE any other name of your choice if you WANT.

Middleware is something that executes between the request and response. In simple words, you can SAY it ACTS as a bridge between the request and response. Similarly In Django when a request is made it MOVES through MIDDLEWARES to views and DATA is passed through middleware as a response. 

USING the session framework, you can easily store and retrieve arbitrary DATA BASED on the pre-site-visitors. It stores data on the server-side and takes care of the process of sending and RECEIVING COOKIES. These cookies just consist of a session ID, not the actual data itself unless you explicitly use a cookie-based backend.

PostgreSQL and MYSQL, SQLite and Oracle. APART from these, DJANGO also supports databases such as ODBC, Microsoft SQL Server, IBM DB2, SAP SQL Anywhere, and Firebird using third-party packages. Note: OFFICIALLY Django doesn’t support any no-SQL databases.

Whenever a request is MADE to a web page, Django creates an HttpRequest object that contains METADATA about the request. After that Django loads the particular view, PASSING the HttpRequest as the first argument to the view function. Each view will be returning an HttpResponse object.
On the big picture following steps occur when a request is RECEIVED by Django:

1. First of the Django settings.py file is loaded which also contain various middleware classes (MIDDLEWARES)
2. The middlewares are also executed in the ORDER in which they are mentioned in the MIDDLEWAREST
3. From here on the request is now moved to the URL Router, who simply gets the URL path from the request and tries to map with our given URL paths in the urls.py. 
4. As soon as it has mapped, it will call the equivalent view function, from where an equivalent response is generated
5. The response also passes through the response middlewares and send back to the client/browser.

Ensure that django.contrib.staticfiles is added to your INSTALLED_APPS

In your settings file. define STATIC_URL for ex.

STATIC_URL = '/static/'

In your Django templates, use the static template tag to create the URL for the GIVEN relative path using the CONFIGURED STATICFILES_STORAGE.

Store your static files in a folder called static in your app. For example my_sample/static/my_sample/abcxy.jpg

Django comes with a built-in user authentication system, which HANDLES objects LIKE users, groups, user-permissions, and few cookie-based user sessions. Django User authentication not only authenticates the user but ALSO authorizes him.

The system CONSISTS and operates on these objects:

• Users
• Permissions
• Groups
• Password Hashing System
• Forms Validation
• A pluggable backend system

Caching refers to the technique of storing the output results when they are processed initially so that next time when the same results are fetched again, instead of processing again those already stored results can be USED, which leads to faster accessing as well us LESS resource utilization. DJANGO provides us with a robust cache system that is able to STORE dynamic web pages so that these pages don’t need to be evaluated again for each request. 

Some of the caching strategies in Django are listed below:

Whenever there is a modification in a model, we may need to TRIGGER some actions. 
Django PROVIDES an elegant way to handle these in the form of signals. The signals are the utilities that allow us to associate events with actions. We can implement these by developing a function that will run when a signal calls it.

List of built-in signals in the models: