from django.db import models
class Post(models.Model):
    title = models.CharField(max_length=255)
    content = models.TextField()
    author = models.CharField(max_length=100)
    published_date = models.DateTimeField(auto_now_add=True)

    def __str__(self):
        return self.title

• Model Inheritance:
  Every model class in Django must inherit from
  models.Model.

• Fields:
  • CharField: A string field for small-to-medium-sized strings.
  • TextField: A field for large text data.
  • DateTimeField: Stores date and time.
  • Other fields include IntegerField, BooleanField, ForeignKey, and many more.

• Constraints:
  • max_length: Specifies the maximum length for fields like CharField.
  • auto_now_add: Automatically sets the field to the current date/time when the object is first created.

• The __str__ method:
  This is a string representation of the object (used in the Django admin interface and elsewhere).
  

Behind the scene

Once you’ve defined your models, Django generates SQL to create necessary database tables.

CREATE TABLE blog_post (
    id INT PRIMARY KEY AUTOINCREMENT,
    title VARCHAR(255),
    content TEXT,
    author VARCHAR(100),
    published_date DATETIME
);

Migrations in Django are a system that manages changes to the database schema over time. They allow to:

• Version control the database schema

• Safely apply changes to the database as Django models evolve.

Migrations are closely tied to the models defiled in the models.py files. Whenever a model is modified (e.g., add a field, rename a field, or change fields type), Django create a migration to apply these changes to the database.

• What problem migrations solve ?

  Schema evolution: As your application grows, you need to modify your database schema to accommodate new Features. Migrations handle it in a controlled way.

  Version control: You can track changes to your database schema and apply appropriate migrations on different environments (e.g., development, testing, production) in a consistent manner.

• Key migration commands ?

  python3 manage.py makemigrationscreate new migration files based on changes in the models.py.

  python3 manage.py migrateapplies migrations to the database, syncing models to the database schema.

• How do migrations work step-by-step ?
  • Model Changes: You modify or add fields to your models in the models.py file.
  • Generate Migrations: Run makemigrations. Django detects changes and creates migration files in the migrations/ folder of each app.
  • Migration Files: Each migration file is a Python script describing the changes. Django generates raw SQL statements behind the scenes based on these files.
  • Apply Migrations: Run migrate to apply the changes to your database.
  • Migration History: Django tracks migrations applied to the database in a special table called django_migrations, ensuring migrations are applied only once.

• What happens if you delete migrations files (not recommended !) ?

  Database Schema: The database changes already applied via migrations will remain intact (nothing breaks in the database).

  Future Migrations: Without the migration history (the deleted files), Django may not be able to track future changes correctly. Deleting migration files might cause issues when attempting to apply new migrations.

  If you want to delete migrations and reset them, you need to carefully manage this by deleting the django_migrations table entries and recreating the migration files in sync with the current schema. This can be tricky and is generally discouraged unless absolutely necessary.

• What happens if you modify the Database directly (Without migrations) ?

  Database Changes: If you modify the database manually (e.g., using SQL in PostgreSQL), Django will be unaware of those changes.

  Desync Between Models and Database: The models and the database schema will fall out of sync. For example, if you rename a column in the database but don’t reflect the change in models.py, Django will still expect the old column name, leading to errors.

  Migrations Won’t Reflect Changes: Future migrations won’t account for manual changes in the database, and you might face issues when running migrate.

  It is always recommended to make changes via migrations (or through Django’s ORM) rather than directly in the database to avoid these problems.

1. Missing migrations:

   Problem: forgetting to create and apply migrations after changing models, leading to inconsistency between the model, code base and and database schema.

   Strategies for Resolution:

   • Manual migration generation: Run python3 manage.py makemigrationsafter changing the model to ensure migrations are created.

   • CI/CD checks: Enforce migration checks in the Continues Integrations pipeline to verify if migrations are missing before merging code. python3 manage.py makemigrations --check.

2. Conflict in Migration files:

   Problem: When multiple developers work on different branches, they might both modify models and generate migrations. This can lead to merge conflicts in migration files when the branches are merged.

   Strategies for Resolution:

   • Sequential migrations: Use Django’s auto-generated migrations names to detect the order in which they were created. After resolving the merge conflict, ensure the migration numbers are sequential (e.g. 0001_initial.py, 0002_auto..).
   • Manual migrations merging: Carefully review the conflicting migrations and consolidate them by generating a new, combined migration file manually if necessary.
   • Migration squashing: Use Django’s squashmigrations command to consolidate multiple migrations into a single one, reducing future chances of conflicts.

3. Out-of-order migrations:

   Problem: Migrations can be applied in an incorrect order, especially when developers pull changes from different branches or manually apply migrations on different environments.

   Strategies for Resolution:

   • Dependency Management: Each migration can specify dependencies using the dependencies attribute in migration files, which ensures they are applied in the correct order.

   • Migration Rollbacks: If migrations are applied out of order, you can roll back migrations using python manage.py migrate <app> <migration_name> to an earlier state and reapply them in the correct sequence.

   • Strict Version Control Practices: Ensure that developers apply migrations only after pulling the latest code to avoid running them out of order.

4. Migrations not reflecting all changes:

   Problem: Sometimes migrations fail to capture all changes in the models, such as renaming fields or changing field properties, especially when those changes are more subtle.

   Strategies for Resolution:

   • Clear __pycache__ and Migration Files: Remove any cached migration files and rerun makemigrations to ensure Django picks up all changes.
   • Manual Edits in Migrations: After running makemigrations, review the generated migration files for correctness, and make manual edits if Django doesn’t detect some changes (e.g., field renaming).
   • Use -empty Flag: If Django is unable to generate a migration, but a database change is required, developers can use python manage.py makemigrations --empty to create a migration file and manually add the necessary operations.

5. Circular dependencies:

   Problem: When two or more migrations depend on each other (i.e., circular dependencies), Django’s migration system cannot resolve the order in which to apply them.

   Strategies for Resolution:

   • Manual Dependency Management: Break the circular dependency by manually specifying dependencies between migrations. You may need to create separate migrations for each app and ensure that one app’s migration depends on another’s.
   • Splitting Migrations: Instead of making complex changes in a single migration, split the migrations into multiple smaller ones that can be applied sequentially.

6. Irreversible migrations:

   Problem: Some migrations cannot be easily reversed (e.g., data migrations, field deletions), which can pose a challenge if you need to rollback the database.

   Strategies for Resolution:

   • Custom Migration Operations: Implement reversible custom migration operations using operations within the migration file. You can define both the forwards and backwards logic to handle more complex cases.
   • Use of RunPython Safely: When using RunPython for data migrations, ensure that both a forward and reverse function are provided, making the migration reversible.
   • Backup and Testing: Always back up the database before running irreversible migrations and test them on a staging environment.

7. Migrations not applied in Production:

   Problem: Migrations may not be correctly applied in production if the deployment pipeline does not include running migrations.

   Strategies for Resolution:

   • Automate Migration Application: Integrate python manage.py migrate as part of the deployment process, so migrations are applied automatically with every deployment.
   • Migration Flags: Use environment-specific flags to determine when migrations should be run (e.g., run migrations only in production environments, not locally).
   • Database Monitoring: Set up monitoring to ensure the schema in production matches the expected state of the models.

8. Database locks during migrations:

   Problem: In production environments with high traffic, long-running migrations (e.g., adding non-nullable columns or altering large tables) can cause database locks, leading to downtime or performance issues.

   Strategies for Resolution:

   • Zero-Downtime Migrations: Use strategies like:
     • Creating nullable fields first, then backfilling data and finally making them non-nullable.
     • Using database-specific tools like PostgreSQL’s CONCURRENTLY for indexing without locking.
     • Splitting migrations into multiple phases (e.g., create the field in one migration, populate it in a second, and drop the old field in a third).
   • Pre-Migration Testing: Test migrations in a staging environment with similar data sizes to anticipate performance issues.

9. Data migrations vs. Schema migrations:

   Problem: Mixing schema migrations with data migrations can result in complex and error-prone migrations, especially when working across different environments.

   Strategies for Resolution:

   • Separate Migrations: Keep schema migrations (like adding/removing columns) separate from data migrations (populating or transforming data) to minimize risk.
   • Transaction Management: Use database transactions carefully (atomic block) during data migrations to ensure consistency. Rollback changes if there are errors during migration.

10. Large number of migrations:

    Problem: Over time, a project can accumulate a large number of migrations, making it harder to manage, and leading to longer migration times.

    Strategies for Resolution:

    • Migration Squashing: Use python manage.py squashmigrations to consolidate multiple migrations into one, reducing the number of migration files and improving performance.
    • Selective Squashing: Only squash migrations for apps that are stable and have undergone significant model changes. Avoid squashing migrations for apps that are still under active development.

11. Foreign key constrains and related models:

    Problem: When working with Foreign Keys, migration dependencies between apps can lead to issues such as missing related models, or circular dependencies.

    Strategies for Resolution:

    • Lazy Model References: Use string-based references (e.g., ForeignKey('app.Model') instead of ForeignKey(Model)) to avoid circular dependencies between migrations across apps.
    • Careful Order of Operations: Handle related models carefully by first creating nullable Foreign Keys, then backfilling them, and finally setting them to non-nullable if needed.

To create a new custom manager, you define a new class that inherits from models.Manager. This allows you to add your own methods that extend or customize the default behavior.

Let’s create a simple model manager.

from django.db import models

class PublishedPostManager(models.Manager):
    def get_queryset(self):
        return super().get_queryset().filter(is_published=True)

class Post(models.Model):
    title = models.CharField(max_length=255)
    content = models.TextField()
    author = models.CharField(max_length=100)
    is_published = models.BooleanField(default=False)
    published_date = models.DateTimeField(null=True, blank=True)

    # Link the custom manager
    published = PublishedPostManager()

    def __str__(self):
        return self.title

• Custom Manager (PublishedPostManager):
  This custom manager overrides the
  get_queryset() method to return only posts where is_published=True.

• Custom Manager Assignment:
  Instead of using
  Post.objects, you would use Post.published to only retrieve published posts.

After linking the custom manager class to the model, we can access it as a model’s attribute which inherits methods for working with the manager.

# Using the default manager (will return all posts)
all_posts = Post.objects.all()

# Using the custom manager (will return only published posts)
published_posts = Post.published.all()

You can have multiple managers on the same model. For example, you might want a default manager that returns all posts, and a custom manager that returns only published posts.

class Post(models.Model):
    title = models.CharField(max_length=255)
    content = models.TextField()
    author = models.CharField(max_length=100)
    is_published = models.BooleanField(default=False)
    published_date = models.DateTimeField(null=True, blank=True)
    # Default manager (Post.objects)
    objects = models.Manager()
    # Custom manager for published posts
    published = PublishedPostManager()
    def __str__(self):
        return self.title

Here, Post.objects will return all posts (published and unpublished), while Post.published will return only published posts.

Custom managers can also include additional methods that return filtered query sets or perform actions. For example, lets add a method that returns all posts written by a particular author:

class PostManager(models.Manager):
    def by_author(self, author_name):
        return self.get_queryset().filter(author=author_name)

class Post(models.Model):
    title = models.CharField(max_length=255)
    content = models.TextField()
    author = models.CharField(max_length=100)
    is_published = models.BooleanField(default=False)
    published_date = models.DateTimeField(null=True, blank=True)

    # Custom manager
    objects = PostManager()

    def __str__(self):
        return self.title

Now, you can query posts my author using the custom method:

# Get all posts by the author "John Doe"
johns_posts = Post.objects.by_author("John Doe")

You can also use custom managers in Django’s Admin interface. For example, you need admin interface to display only published posts.

class PostAdmin(admin.ModelAdmin):
    def get_queryset(self, request):
        qs = super().get_queryset(request)
        return qs.filter(is_published=True)

admin.site.register(Post, PostAdmin)

class PostQuerySet(models.QuerySet):
    def published(self):
        return self.filter(is_published=True)

class PostManager(models.Manager):
    def get_queryset(self):
        return PostQuerySet(self.model, using=self._db)

class Post(models.Model):
    title = models.CharField(max_length=255)
    content = models.TextField()
    author = models.CharField(max_length=100)
    is_published = models.BooleanField(default=False)

    objects = PostManager()

    def __str__(self):
        return self.title

Allows to chain queries in a flexible manner

published_posts = Post.objects.published()

In Django, querysets are lazy. This means that no database query is actually executed until the queryset is evaluated. This feature prevents unnecessary queries and allows you to chain queryset methods without hitting the database repeatedly.

# No database hit yet
posts = Post.objects.all()
# Database query executed when queryset is evaluated (e.g., in a loop)
for post in posts:
    print(post.title)

This laziness can be useful, but it's important to be mindful of when queries are evaluated (e.g., in templates or when passing a queryset to a function).

One of the most common performance problem in Django is the N+1 problem. This occurs when your code queries related modes in a loop, resulting in multiple database hits instead of fetching all the related data in a single query.

select_related is used for foreign key and one-to-one relationships. It performs an SQL join and includes the related object in the same query, reducing the number of db hits.

class Post(models.Model):
    title = models.CharField(max_length=255)
    content = models.TextField()
    author = models.ForeignKey(Author, on_delete=models.CASCADE)
# Without select_related (N+1 problem):
posts = Post.objects.all()
for post in posts:
    print(post.author.name)  # This will execute one query per post (N+1 queries)
# With select_related (solves N+1 problem):
posts = Post.objects.select_related('author')
for post in posts:
    print(post.author.name)  # This will execute only one query

prefetch_related is used for M:M, and reversed foreign key relationships. It performs separated queries for the related objects and does the joining in Python rather than in the database.

class Post(models.Model):
    title = models.CharField(max_length=255)
    tags = models.ManyToManyField('Tag')
# Without prefetch_related:
posts = Post.objects.all()
for post in posts:
    print(post.tags.all())  # Multiple queries for each post (N+1 problem)
# With prefetch_related:
posts = Post.objects.prefetch_related('tags')
for post in posts:
    print(post.tags.all())  # Executes just two queries (one for posts, one for tags)

The N+1 problem happens when the code ends up make one query to fetch the main object (1 query) and additional queries for each related object (N queries). This typically occurs in a loop over related objects without using select_related and prefetch_realted.

Django provides powerful aggregation functions to compute values like count, sum, average, etc.

from django.db.models import Count, Avg

# Get the total number of posts
total_posts = Post.objects.count()
# Get the average number of posts per author
average_posts_per_author = Post.objects.values('author').annotate(total=Count('author')).aggregate(Avg('total'))
# Total number of posts for each author
posts_per_author = Post.objects.values('author__name').annotate(post_count=Count('author'))

By using aggregation, you're leveraging the database to compute totals or averages, which is more efficient than fetching all the data into Python and performing the computation manually.

Indexes are crucial database optimization technique that makes lookups and joins falter. Django allows to specify which fields should be indexed at the model level.

To add an index to a field, use the index=True option in the model’s field definition:

class Post(models.Model):
    title = models.CharField(max_length=255, db_index=True)  # Adds an index on the 'title' field
    content = models.TextField()

Compound, and unique indexes are supported as well by using the Meta class.

class Post(models.Model):
    title = models.CharField(max_length=255)
    content = models.TextField()
    class Meta:
        indexes = [
            models.Index(fields=['title', 'author']),
        ]

Adding the right indexes can significantly improve query performance, but keep in mind that indexes slow down inserts and updates. Only index fields that are frequently queried.

Sometimes all database fields are not needed, especially if a table has a lot of columns or large data. You can optimize performance by limiting the fields retrieved from the database using the only() and defer()methods.

only() This methods retrieves only the fields specified, reducing the amount of data fetched.

# Fetch only the 'title' and 'published_date' fields
posts = Post.objects.only('title', 'published_date')

defer()This method retrieves all fields except the one specified. It’s useful when you want most of the data but want to avoid fetching large fields file TextField.

# Fetch all fields except 'content'
posts = Post.objects.defer('content')

These methods can reduce memory usage and query execution time by retrieving only the necessary data.

When inserting or updating multiple records, Django’s default behavior is to issue one query per record. This can lead to inefficiency in large databases. You can use bulk operation like bulk_create()or bulk_update()to insert or update multiple records within a single query.

bulk_create()

# Insert multiple posts at once
Post.objects.bulk_create([
    Post(title='Post 1', content='Content 1', author=author),
    Post(title='Post 2', content='Content 2', author=author),
])

bulk_update()

# Update multiple posts at once
posts = Post.objects.filter(author=author)
for post in posts:
    post.content = 'Updated content'
Post.objects.bulk_update(posts, ['content'])

These operations are much more efficient than looping over each object and calling save().

Imagine you have a blog with many posts, each of which has an author and tags. You want to display the titles, authors, and tags of the most recent 10 posts.

# Optimized query
posts = (
    Post.objects.select_related('author')   # Avoids N+1 for the 'author' foreign key
        .prefetch_related('tags')           # Prefetches tags to avoid N+1 on many-to-many field
        .only('title', 'author__name')      # Fetches only the necessary fields
        .order_by('-published_date')        # Orders by the most recent posts
        .all()[:10]                         # Limits the result to 10 posts
)

This query optimizes:

• Foreign key retrieval with select_related().

• Many-to-many retrieval with prefetch_related().

• Only fetching necessary fields with only().

• Limiting the number of posts with [:10].

Let’s consider a simple example where we have two models: Author and Post. Each post belongs to a single author (one-to-many relationship), but an author can have many posts.

from django.db import models

class Author(models.Model):
    name = models.CharField(max_length=100)

    def __str__(self):
        return self.name

class Post(models.Model):
    title = models.CharField(max_length=255)
    content = models.TextField()
    author = models.ForeignKey(Author, on_delete=models.CASCADE)

    def __str__(self):
        return self.title

• Each Post has a foreign key field (author), which links it to an Author.

• Each Author can have multiple Post objects, but a Post can only have one Author.

From the Postmodel, you can easily access the related Authorusing the foreign key relationship.

post = Post.objects.get(id=1)
print(post.author.name)  # Access the author of the post

The reverse foreign key is how the Author model accesses all related Post objects. This works because Django automatically creates a reverse relation for each foreign key.

By default, Django creates this reverse relation as related_name if you don’t explicitly set it. In our case, the default reverse relation for Post objects on the Author model would be author.post_set (model name in lowercase with _set suffix).

author = Author.objects.get(id=1)
posts = author.post_set.all()  # Get all posts written by this author
for post in posts:
    print(post.title)

• author.post_set.all() retrieves all Post objects where the author field matches this specific Author.

• This is the reverse access from Author to Post.

By default, Django uses the pattern <model_name>_set to refer to the reverse foreign key. However, you can customize this by using the related_name attribute when defining the ForeignKey.

class Post(models.Model):
    title = models.CharField(max_length=255)
    content = models.TextField()
    author = models.ForeignKey(Author, on_delete=models.CASCADE, related_name='posts')

    def __str__(self):
        return self.title

In this case, you’ve set the related_name to 'posts'. Now, instead of using author.post_set, you can access the related posts like this:

author = Author.objects.get(id=1)
posts = author.posts.all()  # Access all posts related to this author using the custom related_name
for post in posts:
    print(post.title)

In Django you can access objects by Reversed Foreign Key even from the templates.

<h1>{{ author.name }}</h1>

<ul>
    {% for post in author.posts.all %}
        <li>{{ post.title }}</li>
    {% endfor %}
</ul>

You can also perform queries using reverse foreign keys. For example, you might want to get all authors who have written more than 5 posts:

from django.db.models import Count
authors = Author.objects.annotate(post_count=Count('posts')).filter(post_count__gt=5)

Here, Count('posts') counts the number of posts related to each author, and then the queryset filters to only authors with more than 5 posts.

cleaned_data is a dictionary-like attribute that contains the validated data from the form's fields. After a form has been submitted and its data has been validated (using the is_valid() method), the cleaned_data dictionary is populated with the cleaned (validated and converted) data from the form.

class ContactForm(forms.Form):
    name = forms.CharField(max_length=100)
    email = forms.EmailField()
    message = forms.CharField(widget=forms.Textarea)
    
    def clean_email(self):
        email = self.cleaned_data.get('email')
        if not email.endswith('@example.com'):
            raise forms.ValidationError('Email must be from example.com domain')
        return email

class ContactForm(forms.Form):
    name = forms.CharField(max_length=100)
    email = forms.EmailField()
    message = forms.CharField(widget=forms.Textarea)
    
    def clean(self):
        cleaned_data = super().clean()
        name = cleaned_data.get('name')
        message = cleaned_data.get('message')
        
        if name and message:
            if 'urgent' in message and name != 'Admin':
                raise forms.ValidationError('Only Admin can send urgent messages.')
        
        return cleaned_data

• Field Validation:
  • When you call form.is_valid(), Django goes through each field in the form and runs the validation logic for that field. This includes built-in validations like checking if a required field is filled in, or if an email is correctly formatted, as well as any custom validation logic you may have added.
  • If a field's data passes validation, it is added to the cleaned_data dictionary.

• Data Cleaning and Conversion:
  • During validation, the data is also "cleaned" and converted into the appropriate Python data types. For example, if a form field is a DateField, the data entered as a string (e.g., "2024-09-04") is converted into a Python datetime.date object and stored in cleaned_data.

• Accessing cleaned_data:
  • Once the form is validated, you can access the cleaned_data dictionary to retrieve the validated data and perform further processing, such as saving it to a database or using it in some other way.

1. ValidationError

• What It Is:
  • ValidationError is the most common error raised during form validation. It occurs when the data provided by the user does not meet the validation criteria set by the form fields or custom validation methods.

• Examples:
  • Entering an invalid email address in an EmailField.
  • Providing a string where an integer is expected in an IntegerField.

2. TypeError

• What It Is:
  • TypeError can occur if you attempt to perform an operation on a data type that isn’t compatible with that operation, often resulting from incorrect data types being passed to form fields.

• Examples:
  • Passing a list instead of a string to a CharField.
  • Using an integer where a DateField expects a date object.

• Common Scenarios:
  • When writing custom validation logic and accidentally performing operations on the wrong data type.

3. ValueError

• What It Is:
  • ValueError occurs when a function receives an argument of the right type but with an inappropriate value, particularly in custom validation logic.

• Examples:
  • Trying to convert a string that doesn’t represent a valid number to an integer.

• Common Scenarios:
  • When manually processing form data in a view or within custom clean() methods.

4. KeyError

• What It Is:
  • KeyError can occur when you try to access a key in a dictionary that doesn’t exist. In form validation, this might happen if you attempt to access a field in cleaned_data that hasn’t been validated yet or doesn’t exist in the form.

• Examples:
  • Accessing a non-existent key in cleaned_data.

• Common Scenarios:
  • In custom clean() methods where you access multiple fields together without checking if they exist first.

5. AttributeError

• What It Is:
  • AttributeError occurs when you try to access or call an attribute or method that doesn’t exist on an object. In forms, this can happen if you assume a certain field or method exists when it does not.

• Examples:
  • Attempting to call a method that is not defined on a form field.

• Common Scenarios:
  • When you have a typo in field names or when the form or model object is incorrectly referenced.

6. IntegrityError

• What It Is:
  • IntegrityError occurs when a form tries to save data that violates database constraints, such as uniqueness or foreign key constraints.

• Examples:
  • Trying to create a new user with a username that already exists if the username field is marked as unique.

• Common Scenarios:
  • When saving form data directly to the database, especially in ModelForm.

7. MultiValueDictKeyError

• What It Is:
  • MultiValueDictKeyError is a subclass of KeyError and occurs when you try to access a key in a Django request's POST or GET data (which are MultiValueDicts) that doesn’t exist.

• Examples:
  • Accessing a non-existent key in request.POST or request.GET.

• Common Scenarios:
  • When processing form data directly from the request object without using request.POST.get() or request.GET.get() methods that handle missing keys more gracefully.

8. FieldError

• What It Is:
  • FieldError occurs when there is a problem with a form field, such as when trying to set a form field that doesn't exist or when a field is improperly configured.

• Examples:
  • Trying to set a field that is not part of the form.

• Common Scenarios:
  • When dynamically adding or modifying form fields.

9. ImproperlyConfigured

• What It Is:
  • ImproperlyConfigured occurs when Django is not properly configured, which could include issues in form setup or field configuration.

• Examples:
  • Misconfiguring a form field that expects a certain setting to be present.

• Common Scenarios:
  • When configuring forms or integrating them with other Django components.

from django import forms

class UserRegistrationForm(forms.Form):
    username = forms.CharField(max_length=100, widget=forms.TextInput(attrs={'class': 'form-control', 'placeholder': 'Username'}))
    password = forms.CharField(widget=forms.PasswordInput(attrs={'class': 'form-control'}))
    email = forms.EmailField(widget=forms.EmailInput(attrs={'class': 'form-control', 'placeholder': 'Email'}))
    birth_date = forms.DateField(widget=forms.SelectDateWidget(years=range(1980, 2025)))

In this example:

• widget=forms.TextInput(...): Specifies a TextInput widget for the username field, with additional HTML attributes like class and placeholder.

• widget=forms.PasswordInput(...): Uses a PasswordInput widget for the password field, rendering it as a password input box.

• widget=forms.EmailInput(...): Customizes the EmailField with an EmailInput widget.

• widget=forms.SelectDateWidget(...): Provides a dropdown for selecting a date with a custom range of years.

1. TextInput: widget=forms.TextInput(attrs={'class': 'form-control'})

2. PasswordInput: widget=forms.PasswordInput(attrs={'class': 'form-control'}).

3. EmailInput: widget=forms.EmailInput(attrs={'placeholder': 'Enter your email'}).

4. TextArea: widget=forms.Textarea(attrs={'rows': 4, 'cols': 15}).

5. CheckboxInput: widget=forms.CheckboxInput().

6. Select: widget=forms.Select(choices=[('1', 'One'), ('2', 'Two')]).

7. RaidioSelect: widget=forms.RadioSelect(choices=[('M', 'Male'), ('F', 'Female')]).

8. FileInput: widget=forms.FileInput().

9. DateInput: widget=forms.DateInput(attrs={'type': 'date'})

10. SelectDatewidget: widget=forms.SelectDateWidget(years=range(1980, 2025)).

11. TimeInput: widget=forms.TimeInput(attrs={'type': 'time'}).

12. NumberInput: widget=forms.NumberInput().

You can customize widgets by passing additional attributes using the attrs argument. This allows you to add CSS classes, placeholder text, or any other HTML attributes to the rendered widget.

class CommentForm(forms.Form):
    comment = forms.CharField(widget=forms.Textarea(attrs={
        'class': 'form-control',
        'rows': 5,
        'placeholder': 'Enter your comment here...'
    }))

Build custom widgets

If the built-in widgets don’t meet your requirements, you can create custom widgets by subclassing django.forms.widgets.Widget and implementing the necessary methods.

from django.forms.widgets import Widget

class CustomTextInput(Widget):
    template_name = 'custom_widgets/custom_text_input.html'

    def __init__(self, attrs=None):
        super().__init__(attrs)

    def get_context(self, name, value, attrs):
        context = super().get_context(name, value, attrs)
        context['custom_attribute'] = 'custom_value'
        return context

Form Validators: These are applied to the entire form. They are typically used when you need to validate the relationship between multiple fields or the overall consistency of the form data.

Form validators are typically used when the validation logic depends on more than one field. You can override the clean method in your form to implement form-level validation.

from django import forms
from django.core.exceptions import ValidationError

class SignupForm(forms.Form):
    username = forms.CharField(max_length=100)
    email = forms.EmailField()
    confirm_email = forms.EmailField()

    def clean(self):
        cleaned_data = super().clean()
        email = cleaned_data.get("email")
        confirm_email = cleaned_data.get("confirm_email")

        if email != confirm_email:
            raise ValidationError("Emails do not match")

In this example, the form checks if the email and confirm_email fields match. If they don't, a ValidationError is raised, which will prevent the form from being submitted and display an error message to the user.

When using Model Forms, validators can be applied directly to the model fields in the model definition, and they will automatically be applied to the corresponding form fields.

from django.db import models
from django.core.validators import MinLengthValidator

class User(models.Model):
    username = models.CharField(max_length=100, validators=[MinLengthValidator(6)])
    email = models.EmailField()

class UserForm(forms.ModelForm):
    class Meta:
        model = User
        fields = ['username', 'email']

In this case, the MinLengthValidator is applied to the username field at the model level, and it will be enforced when the field is used in a form.

Field Validators: These are applied to individual form fields. They are used to ensure that a single field meets specific criteria, such as being a valid email address, having a minimum length, or matching a regular expression pattern.

Django provides a set of built-in validators that you can attach to form fields. Additionally, you can create custom validators if the built-in ones don't meet your needs.

Built-in Field Validators

Some common built-in validators include:

• MinLengthValidator: Ensures the input has at least a minimum number of characters.

• MaxLengthValidator: Ensures the input does not exceed a maximum number of characters.

• EmailValidator: Ensures the input is a valid email address.

• URLValidator: Ensures the input is a valid URL.

• RegexValidator: Ensures the input matches a specified regular expression.

  from django import forms
  from django.core.validators import MinLengthValidator, EmailValidator
  
  class UserRegistrationForm(forms.Form):
      username = forms.CharField(max_length=100, validators=[MinLengthValidator(6)])
      email = forms.EmailField(validators=[EmailValidator()])
      password = forms.CharField(widget=forms.PasswordInput, validators=[MinLengthValidator(8)])

Custom validators

from django import forms
from django.core.exceptions import ValidationError

def validate_even(value):
    if value % 2 != 0:
        raise ValidationError(f'{value} is not an even number')

class NumberForm(forms.Form):
    number = forms.IntegerField(validators=[validate_even])

In this example, the validate_even function checks if the input value is an even number. If it's not, a ValidationError is raised, which will be displayed to the user.

1. extra: int | None = Nonethe number of forms displayed.

2. max_num: int | None = None : Limits the max number of forms can be displayed.

3. can_order: bool = False: Adds an order field for each form in a formset, allowing user to specify the order of the forms.

4. can_delete: bool = True: Adds a checkbox to each form that allows form to be marked for deletion when the formset is submitted.

5. min_num: int = 0 : Enforces a minimum number of forms that must be submitted in the formset.

6. validation_min: bool = False : raises a validation error is min_numrule is violated submitting the form.

7. validate_max: bool = False: Raises a validation error if submitting the form the max_numrule was violated.

8. formset: FormasetClass: Allows to specify custom formset class…

9. fields: list[str] | None = None: Specifies which fields should be included in the form when using a ModelFormSet.

10. exclude: Specifies which fields should be excluded from the form when using a ModelFormSet.

11. widgets: dict:Allows you to override the default widgets for specific fields in the formset.

These are used to manage multiple instances of a standard Django form (not tied to any model). You use the formset_factory method to create a basic formset.

from django import forms
from django.forms import formset_factory

class ContactForm(forms.Form):
    name = forms.CharField()
    email = forms.EmailField()

ContactFormSet = formset_factory(ContactForm, extra=3)

Here, ContactFormSet is a formset that will display three ContactForm instances by default.

Parameters:

These are used to manage multiple instances of a form tied to a Django model. The forms in a model formset correspond to model instances, and they can be used to create, update, or delete multiple model instances. You use the modelformset_factory method to create a model formset.

from django import forms
from django.forms import modelformset_factory
from myapp.models import Author

class AuthorForm(forms.ModelForm):
    class Meta:
        model = Author
        fields = ['name', 'email']

AuthorFormSet = modelformset_factory(Author, form=AuthorForm, extra=2)

This AuthorFormSet will display forms for two new Author instances by default, alongside forms for existing authors.

These are a specialized version of model formsets used to manage related objects, typically for handling related models in a parent-child relationship (e.g., managing books related to a specific author). Inline formsets are created using the inlineformset_factory method.

Inline formsets are useful for managing related objects. For example, if you have an Author model and a related Book model, you can manage books related to a specific author.

from django.forms import inlineformset_factory
from myapp.models import Author, Book

BookFormSet = inlineformset_factory(Author, Book, fields=('title', 'publication_date'), extra=1)

This BookFormSet can be used to display and manage books related to a specific author.

Key Features

• extra Parameter: Controls how many empty forms are displayed in addition to the existing forms.

• can_delete Parameter: Allows you to include a checkbox in each form to mark it for deletion.

• can_order Parameter: Adds an ordering field to each form in the formset, useful for ordering objects in a list.

from django.test import TestCase

from .forms import ContactForm

class ContactFormTest(TestCase):

    def test_contact_form_valid(self):
        form_data = {
            'name': 'John Doe',
            'email': 'john@example.com',
            'message': 'This is a test message.'
        }
        form = ContactForm(data=form_data)
        self.assertTrue(form.is_valid())

In this test:

• You pass valid data to the form and check if form.is_valid() returns True.

Here, you test the behavior of the form when given invalid or missing data. You can check that the form returns errors for the required fields or for any custom validation rules.

class ContactFormTest(TestCase):

    def test_contact_form_invalid(self):
        # Missing required fields
        form_data = {
            'name': '',
            'email': 'invalid-email',
            'message': ''
        }
        form = ContactForm(data=form_data)
        self.assertFalse(form.is_valid())
        self.assertEqual(len(form.errors), 3)  # We expect 3 errors: name, email, message
        self.assertIn('name', form.errors)
        self.assertIn('email', form.errors)
        self.assertIn('message', form.errors)

If your form contains custom validation methods (e.g., clean_<field>() methods), you should test those as well. Example: Suppose you have a custom validation method that checks if the email domain is example.com.

class ContactForm(forms.Form):
    name = forms.CharField(max_length=100)
    email = forms.EmailField()
    message = forms.CharField(widget=forms.Textarea)

    def clean_email(self):
        email = self.cleaned_data.get('email')
        if not email.endswith('@example.com'):
            raise forms.ValidationError("Email must be from the domain 'example.com'")
        return email

class ContactFormTest(TestCase):

    def test_contact_form_custom_email_validation(self):
        form_data = {
            'name': 'John Doe',
            'email': 'john@gmail.com',
            'message': 'This is a test message.'
        }
        form = ContactForm(data=form_data)
        self.assertFalse(form.is_valid())
        self.assertIn('email', form.errors)
        self.assertEqual(form.errors['email'], ["Email must be from the domain 'example.com'"])

You can also test how the form binds data and initializes with it, ensuring that form fields hold the correct values when rendered back to the user after a failed submission.

class ContactFormTest(TestCase):

    def test_contact_form_bound_data(self):
        form_data = {
            'name': 'John Doe',
            'email': '',
            'message': 'This is a test message.'
        }
        form = ContactForm(data=form_data)
        self.assertFalse(form.is_valid())
        self.assertEqual(form.cleaned_data['name'], 'John Doe')
        self.assertEqual(form.cleaned_data['message'], 'This is a test message.')
        self.assertNotIn('email', form.cleaned_data)  # Email is invalid, so it's not in cleaned_data

While not common, you can test how a form is rendered by checking if the expected fields are in the HTML output. This ensures that forms are displayed correctly.

class ContactFormTest(TestCase):

    def test_contact_form_rendering(self):
        form = ContactForm()
        rendered_form = form.as_p()
        self.assertIn('name', rendered_form)
        self.assertIn('email', rendered_form)
        self.assertIn('message', rendered_form)

You can authenticate users based on their session key. Each website visitor get a cookie ‘session id’ based on this cookie Django assign a session_key to each `session id'.

User Permissions: Django provides a flexible system for defining and assigning permissions to users. Permissions can be assigned directly to individual users or to groups. These permissions control what actions users can perform within the application, such as creating, reading, updating, or deleting specific types of data.

from django.urls import path
from django.contrib.auth.decorators import login_required
from . import views

urlpatterns = [
    path('create', login_required(views.create), name='create'),
    path('<str:slug>', login_required(views.index), name='index'),
    path('', login_required(views.home), name='home'),
]

from django.contrib.auth.decorators import login_required


@login_required
def home_view(request)
	return HTTPResponse('<h1>Home Page</h1>')

from django.contrib.auth.mixins import LoginRequiredMixin
from django.views.generic import TemplateView

class ProtectedView(LoginRequiredMixin, TemplateView):
    template_name = 'protected_page.html'

    # Optionally, you can set a custom `login_url` for this view
    login_url = '/custom_login/'
    
    # Optionally, you can specify a redirect field name (default is `next`)
    redirect_field_name = 'redirect_to'

You can create a custom permission object and add it to a specific user(s) or group(s).

Each user present in a group will automatically share permissions that were chosen for the group.

Via Django admin panel

1. Add a new group in Django Admin panel, name it.

2. Choose permissions for this group.

Via Django shell

1. Open Django shell: python3 manage,py shell .

2. Import required modules:
   1. from django.contrib.auth.models import Group, Permission, User
   2. from django.contrib.contenttypes.models import ContentType .

3. Create a new Group:
   1. mod, created = Group.object.get_or_create(name="mod") Name can be any.

4. After creating the group add permissions to it:
   1. Find appropriate permissions:
      1. Get a model content type, so you could find permissions related to a particular model:

         ct = ContentType.object.get_for_model(model=Poster) .

      2. Get a Query-Set of permission for the model: perms = Permission.object.filter(content_type=ct) .
   2. Add permissions to the group: mod.Permissions.add(*perms) ,

      you can either unpack all avail permissions or add them one by one.

5. Add a User to the Group:
   1. Get a user: user = User.object.filter(username="sergei").first().
   2. Add the user to the group: mod.user_set.add(user).

SELECT 
	auth_group.name AS groupname,
	auth_user.username,
	auth_user.is_staff
FROM auth_user
LEFT JOIN auth_user_groups ON auth_user.id = auth_user_groups.user_id
LEFT JOIN auth_group ON auth_group.id = auth_group.id;