Django MCQ Questions

The command 'manage.py inspectdb' introspects an existing database and outputs Django model code. This is useful for integrating legacy databases or generating models from existing schemas. The command examines database tables and creates corresponding Django model definitions. You can redirect output to a file: manage.py inspectdb > models.py. Review and edit the generated models as needed - inspectdb provides a starting point but may require adjustments for Django best practices.

Use User.objects.all().order_by('-name')[:10] to get the first 10 users sorted by name descending. The order_by() method sorts the QuerySet; the minus sign '-' indicates descending order. The slice [:10] limits results to the first 10 records. This generates efficient SQL with ORDER BY and LIMIT clauses. You can chain multiple order_by fields: order_by('-name', 'id'). Slicing a QuerySet doesn't execute the query until evaluation, maintaining Django ORM's lazy evaluation.

Use {% csrf_token %} inside the <form> tag. The correct syntax is: <form action='' method='post'>{% csrf_token %} ... </form>. This template tag generates a hidden input field with a CSRF token that Django validates on form submission. CSRF (Cross-Site Request Forgery) protection is enabled by default in Django. The token ensures requests originate from your site, not malicious third parties. Without the CSRF token, POST requests will be rejected with a 403 Forbidden error.

FBV stands for Function Based Views and CBV stands for Class Based Views. These are two approaches to writing views in Django. FBVs are simple Python functions that take a request and return a response - straightforward and explicit. CBVs are Python classes that provide reusable functionality through inheritance and mixins - more powerful but complex. CBVs include generic views like ListView, DetailView, CreateView. Choose FBVs for simple views, CBVs when you need code reuse or complex behavior.

The command './manage.py sql myapp' prints the CREATE TABLE SQL statements for the specified app. This shows the SQL that would be executed to create database tables for your models. While deprecated in newer Django versions (use 'manage.py sqlmigrate' instead), it's useful for understanding the database schema Django generates. The command doesn't execute the SQL, just displays it. This helps verify table structures and debug database-related issues.

settings.py holds the configuration for the whole Django project, including installed apps, databases, middleware, templates and time zone.

SlugField has a default max_length of 50 characters. A slug is a URL-friendly string containing only letters, numbers, hyphens, and underscores. SlugField is essentially a CharField with slug validation. You can override: slug = models.SlugField(max_length=100). Slugs are commonly used in URLs for SEO-friendly paths. Use slugify() utility to convert strings to slugs. Consider unique=True for slugs used in URLs to prevent duplicates. Slugs should be ASCII-only for maximum URL compatibility.

python manage.py startapp users creates a new app folder named users with models, views and other starter files.

Django's documentation recommends mod_wsgi, an Apache module that hosts Python WSGI applications, as the easiest and most stable deployment option in most cases.

STATIC_ROOT defines the absolute filesystem path where all static files will be collected when you run 'python manage.py collectstatic'. This command gathers static files from all apps and specified directories into one location for production deployment. The production web server (like Nginx or Apache) then serves files from this directory. STATIC_ROOT is different from STATICFILES_DIRS (source locations) and should only be used in production, not development.

The @sensitive_variables decorator hides sensitive information from error reports. Apply it to functions with sensitive data like passwords or API keys: @sensitive_variables('password', 'api_key'). When an error occurs, these variables appear as '********************' in error reports instead of showing actual values. Without arguments, it hides all local variables. Related decorator @sensitive_post_parameters hides specific POST parameters. These decorators prevent accidentally exposing credentials in error emails or logs.

The result is 'Live long and ...' (truncates to 3 words with ellipsis). The truncatewords filter shortens text to specified word count, adding '...' if truncated. Django capitalizes first letter by default. For character truncation, use truncatechars. Example: {{'text'|truncatewords:5}} keeps first 5 words. The HTML-aware version is truncatewords_html. Truncate filters are useful for previews, summaries, or limiting text length in templates. The filter preserves whole words, not cutting mid-word. Use for clean text display in listings.

Use 'class Rainbow:' to define a class in Python (note the capital C in 'class'). The syntax is: class ClassName:, followed by indented class body. Optionally inherit from parent: class Rainbow(ParentClass):. In Python 3, classes implicitly inherit from object. Use def for functions/methods, not classes. Export doesn't exist in Python (it's JavaScript). Python uses significant whitespace and colons for blocks. For Django models, use: class Rainbow(models.Model):. Follow PascalCase for class names.

IntegrityError is raised when violating database integrity constraints like unique fields, foreign key constraints, or non-null constraints. When you try to save a duplicate value in a field with unique=True, Django raises django.db.IntegrityError. Catch this exception to handle duplicates gracefully: try: obj.save() except IntegrityError: # handle duplicate. ValidationError is for form/model validation, ObjectDoesNotExist for queries. IntegrityError comes from the database level.

manage.py is the command line tool Django provides for managing projects and applications. It's automatically created in your project directory when you run django-admin.py startproject. Manage.py provides commands like runserver, migrate, makemigrations, createsuperuser, test, shell, and more. It's a wrapper around django-admin that sets the DJANGO_SETTINGS_MODULE environment variable to your project's settings. Use manage.py for project-specific tasks. Pip and easy_install are package managers, not Django-specific tools.

A class-based view is added to a URLconf with YourView.as_view(), which returns a function that Django can call for each request.

The correct syntax is (r'^pattern/$', YourView.as_view()). The as_view() method is essential for class-based views because it converts the class into a callable view function that Django's URL dispatcher can use. This method handles the request/response cycle and dispatches to the appropriate HTTP method handler (get, post, etc.) within the class. Simply using the class name without as_view() will not work.

python manage.py runserver starts Django's built-in development server, on port 8000 by default.

The correct syntax is: url(r'^admin/', include(admin.site.urls)). This URL pattern routes all URLs starting with 'admin/' to Django's admin site. The include() function delegates URL handling to admin.site.urls, which contains all admin-specific URL patterns. The r'^admin/' is a regular expression pattern. Make sure to import admin and include from their respective modules. This pattern is typically placed in the project's main urls.py file.

Either use the 'fields' attribute (to include specific fields) or 'exclude' attribute (to exclude specific fields) in the form's Meta class. For example: class Meta: model = MyModel; fields = ['name', 'email'] or exclude = ['internal_field']. You can also use fields = '__all__' to include all model fields. Never use both fields and exclude together. Using fields is more explicit and safer - if you add model fields later, they won't automatically appear in forms. Always define fields or exclude in ModelForms.

A good Django app does one small, specific job and can be reused in any number of Django projects.

The collectstatic command takes all static files from your project and apps, and copies them into the folder specified by STATIC_ROOT in settings.py. This centralizes static files for efficient serving in production. In development, Django serves static files automatically, but in production, web servers like Nginx or Apache serve files from STATIC_ROOT. The command finds static files in STATICFILES_DIRS and each app's static directory. Run before deploying to production to ensure all CSS, JavaScript, and images are properly served.

The makemessages command pulls out all strings marked for translation (using gettext, ugettext, etc.) and creates/updates message files (.po files) in the locale directory. These files contain original strings and their translations. Run makemessages when you add or change translatable strings. It scans Python code and templates for translation markers. After translating strings in .po files, run compilemessages to create binary .mo files. This is part of Django's internationalization (i18n) workflow.

Many to one: Many instances of B can have one instance of A. A ForeignKey creates a many-to-one relationship. Multiple B objects can reference the same A object, but each B object references only one A object. For example, many articles can belong to one author. The ForeignKey is placed on the 'many' side. For one-to-many from A's perspective, use the reverse relation (a.b_set.all()). For one-to-one relationships, use OneToOneField. For many-to-many, use ManyToManyField.

WSGI (Web Server Gateway Interface) is an interface specification that defines how web servers communicate with Python web applications/frameworks. It's a standard protocol between web servers (Nginx, Apache) and Python applications (Django, Flask). WSGI isn't a server or module - it's a specification. Django provides wsgi.py that creates a WSGI application. WSGI servers like Gunicorn, uWSGI, or mod_wsgi implement this interface to run Django in production. It enables Python web apps to work with any WSGI-compliant server. Essential for deploying Django applications.

Use RequestContext with context processors to make variables available to all templates. Context processors are functions that return dictionaries added to every RequestContext. Configure in settings.py TEMPLATES OPTIONS context_processors. For example, create a context processor: def my_processor(request): return {'my_var': 'value'}. Add it to settings: 'context_processors': [..., 'myapp.context_processors.my_processor']. This makes my_var available in all templates. Session variables are per-user. Global variables don't work with multiple requests. Adding to template context is per-view only.

No exception will be raised because POST is allowed by the decorator. The @require_http_methods(['GET', 'POST']) decorator restricts the view to only accept GET and POST requests. If a different HTTP method (like PUT, DELETE, PATCH) is used, Django raises HttpResponseNotAllowed (status 405). Since the question asks about using POST, which is explicitly allowed in the decorator's list, no exception occurs. The decorator is useful for enforcing HTTP method constraints on function-based views.

A Validator is a callable that takes a value and raises ValidationError if validation fails. Validators enforce data integrity and business rules. Django provides built-in validators (EmailValidator, URLValidator, MinValueValidator) and allows custom validators. Example: def validate_even(value): if value % 2: raise ValidationError('Must be even'). Apply via model field validators parameter or form clean methods. Validators are reusable across models and forms. They separate validation logic from field definitions, promoting clean code architecture and reusability.

Dijit is Dojo's UI Library, providing a comprehensive set of widgets and UI components. It includes form controls, layout containers, menus, dialogs, and more. Dijit widgets are accessible, themeable, and internationalized. They follow best practices for web accessibility and keyboard navigation. While Dijit is part of the Dojo Toolkit (not Django), it can be used with Django for building rich client-side interfaces.

manage.py runserver accepts an IP:port argument, so manage.py runserver 12.34.56.78:8080 runs the server on that address and port.

Subclass django.contrib.auth.models.AbstractUser and add extra fields. This approach gives you all default user fields plus your custom fields in one model. Set AUTH_USER_MODEL = 'app.CustomUser' in settings.py BEFORE first migration. AbstractUser includes username, email, password, etc. For significantly different user models, use AbstractBaseUser (more work but more flexibility). Proxy models can't add fields. One-to-one relationships work but are more complex. Subclassing AbstractUser is Django's recommended approach for new projects.

A Validator is a callable that takes a value and raises ValidationError if the value fails validation criteria. Validators enforce business rules and data integrity. Django provides built-in validators like EmailValidator, URLValidator, MinValueValidator, MaxValueValidator. Custom validators are simple functions: def validate_even(value): if value % 2 != 0: raise ValidationError('Must be even'). Apply to model fields via validators parameter or use in form clean methods. Validators separate validation logic from form/model definitions, promoting reusability.

Add abstract=True in the Meta class to create an abstract model. Abstract models are base classes that won't create database tables. For example: class Meta: abstract = True. Child models inheriting from abstract models get the parent's fields without creating a table for the parent. Abstract models are useful for common field sets or methods shared across models. They differ from multi-table inheritance (concrete parents create their own tables) and proxy models (same table, different Python behavior).

The typical flow is: URL → View → Template. Django receives request, matches URL pattern in urls.py, calls the corresponding view function/class, view processes logic and renders template with context, template generates HTML, view returns HttpResponse. Middleware wraps this process. Models are accessed by views (not directly in the cycle). Forms are handled in views. The cycle: Request → Middleware → URL → View → Model (if needed) → Template → Response → Middleware → Client. Understanding this flow is fundamental to Django development.

The command 'django-admin.py startproject myproject' creates a new Django project. This generates a directory structure with manage.py, settings.py, urls.py, and wsgi.py files. Django-admin.py is the command-line utility for administrative tasks. The startproject command sets up the basic project skeleton with all necessary configuration files. After creating the project, navigate into the directory and use manage.py for further commands.

Use order_by('?') to randomly order a QuerySet. The question mark tells Django to order randomly. For example: MyModel.objects.order_by('?'). Note that random ordering can be expensive on large datasets as it requires the database to generate random values for each row. For better performance on large datasets, consider implementing random selection at the application level or using database-specific random functions. Random ordering is useful for features like 'random article' or shuffled quiz questions.

TypeError is raised because the correct parameter name is blog__id (double underscore), not blog_id (single underscore). Django uses double underscores to span relationships. If 'blog' is a ForeignKey, use blog__id=4 or simply blog=4. The single underscore syntax would only work if the field is actually named 'blog_id' (like if you explicitly set db_column='blog_id'). This is a common mistake - remember Django's __ syntax for lookups and relationship traversal.

The table name is question_choice (app_name_model_name in lowercase). Django automatically generates database table names as <app_label>_<model_name>, all lowercase. For a model 'Choice' in app 'question', the table becomes 'question_choice'. You can override this using db_table in Meta class: class Meta: db_table = 'custom_name'. Understanding this naming convention is important when writing raw SQL queries or integrating with legacy databases.

A Django project is the collection of settings, configuration files and apps that together make up a website.

ObjectDoesNotExist (or more specifically, Poll.DoesNotExist) is raised when get() finds no matching object. The get() method expects exactly one result - it raises ObjectDoesNotExist if zero results are found, and MultipleObjectsReturned if more than one result is found. Use try-except blocks to handle this: try: poll = Poll.objects.get(id=1) except Poll.DoesNotExist: # handle. Alternatively, use filter() which returns empty QuerySet instead of raising exception, or get_or_404() in views.

The syntax is: user = models.ForeignKey(User). This creates a many-to-one relationship where multiple instances of the current model can reference a single User instance. ForeignKey creates a database column that stores the primary key of the related User. In newer Django versions, you should also specify on_delete behavior, like models.ForeignKey(User, on_delete=models.CASCADE), to define what happens when the referenced User is deleted.