Django Day 37: OR Conditions and Query Performance

🚀 Django Day 34 — Updating Models & Running New Migrations ⚙️📚 After learning how to insert and view data in the database yesterday, today I focused on updating my models by adding more details (columns) to the database tables — such as author and is_bestselling fields 🧩✨. To apply these updates, I first created a new migration by running: “python manage.py makemigrations” ⚙️ However, it didn’t work at first 😅 — Django prompted me to provide a default value for the new fields I added. This happened because the database already contained data from before, and Django didn’t know what values to assign to the new columns. So, I fixed the issue by adding a default value and setting null=True in my model. Then I re-ran the command, and Django successfully generated a new migration file named something like “0002_....py” ✅ Next, I executed the migration using: “python manage.py migrate” 🖥️ This applied the changes to the database, officially updating the table structure with my new model fields 🎯 Finally, I opened the Django shell again using: “python manage.py shell” — to confirm that everything worked perfectly and my changes were now reflected in the database 💪📊 There’s a video below showing how the entire process looks like now 🎥 #Django #Python #Database #Migrations #Models #SQLite #BackendDevelopment #WebDevelopment #100DaysOfCode #LexissLearns 🚀💡

🚀 Django Day 36 — Using .create() + Filtering & Querying Data 🔍📚 Back in Day 33, I learnt how to insert data into the database by creating an object and then calling the save method. But today, I discovered a much cleaner and faster way to add data — using Django’s create() method ⚡📘 Instead of creating an object first and then saving it, I can simply call the create method like: Book.objects.create(title = “…”, author = “…”, rating = …) This instantly creates and saves the record in one step — no need to call save separately. Super efficient and clean 😎✨ After that, I learnt about filtering and querying, which allow me to search the database much faster and get exactly the data I want. Here’s what they help me do: 🔎 Filtering Filtering allows me to get a specific set of records that match certain conditions. For example, if I want books with rating above 4, or books written by a particular author — I can filter and retrieve only those ones. It’s like telling the database: “I only want items that match this condition.” 🔎 Querying Querying in general means asking the database for information. I can get: • all the books • the first or last book • a specific book by its ID • books that meet multiple conditions And so much more — all by using Django’s query methods. Together, filtering and querying make accessing and organising data super fast and very precise. Instead of scrolling through everything, I can pull out exactly what I need in seconds ⚡📂 Today’s session really showed me how powerful Django’s ORM is — writing Python code but performing deep SQL-level operations under the hood. Love it! 💪🔥 There’s a video below showing me trying out create(), filter(), and different queries 👇🎥 #Django #Python #Database #Queries #Filtering #ORM #BackendDev #WebDevelopment #100DaysOfCode #LearningJourney #LexissLearns 🚀💡

🚀 Django Day 31 — Understanding SQL & Discovering Django Models 🧠📚 Since I’ve already chosen SQL as my approach for handling databases, today I decided to dive deeper into how SQL actually works and how it connects with Django 💻. The general process of working with SQL involves three key steps: i.) Creating tables and setting their schema (done once the database is initialized). ii.) Inserting data into those tables — adding records that represent real information. iii.) Retrieving data when needed — using SQL queries to fetch or manipulate stored records 🔍. While learning this, I discovered that Django makes this process much easier through a powerful built-in feature called Models 🧩. Models allow me to describe my data structure (like a table schema) directly in Python code — and Django automatically translates it into SQL behind the scenes. This means I can define how my data should look, and Django handles all the complex SQL for me 😎. To put this into practice, I created a new project named “Book_Store”, and within it, an app called “book_outlet”. Inside the app’s built-in models.py file, I started defining my first model. In the short video below, you’ll see how describing MySQL with python looks like, all thanks to Django’s Model system! ⚙️📖 #Django #Python #SQL #Databases #DjangoModels #BookStoreProject #BackendDevelopment #WebDevelopment #100DaysOfCode #LearningInPublic #LexissLearns 🚀

Your Django queries are probably slower than they need to be. I spent 3 months optimizing a production app and discovered 5 critical ORM mistakes: 🔴 N+1 Queries - Fetching related objects in loops instead of using select_related() and prefetch_related(). This killed our database. 🔴 No Query Optimization - Using .all() without filtering. We were pulling millions of records unnecessarily. 🔴 Missing Indexes - Database indexes on foreign keys can improve speed by 100x. 🔴 Lazy Evaluation Abuse - Not caching querysets when needed. Querysets re-execute every time. 🔴 Raw SQL When ORM Works - Raw queries bypass Django's protections and are harder to maintain. The fix? Use .only(), .defer(), and analyze your queries with django-debug-toolbar. Result: API response time went from 2.3s → 340ms ⚡ If you're building Django apps, audit your queries this week. It's one of the easiest wins you'll get. What's the biggest performance issue you've faced? Drop it below 👇 #DjangoORM #Django #Python #DatabaseOptimization #BackendDevelopment #WebDevelopment #PerformanceTuning #APIDevelopment #SoftwareEngineering #TechTips #PythonDeveloper #DatabaseManagement #QueryOptimization #DjangoFramework #CodingTips

Building Smarter and Faster Access Control in Django Recently, I spent some time refining how branch-level access works in one of my Django projects, and I decided to handle the filtering directly inside a custom QuerySet instead of in the views or serializers. This small change ended up making the entire access control system both cleaner and faster. I created a for_user() method that checks if the user is authenticated, looks up the branches they’ve been approved for, and automatically filters the data so the user only sees records belonging to those branches. If they have no approved branches, the queryset simply returns nothing. It’s straightforward and very reusable. One thing I really love about placing this logic at the model level is the performance benefit. When Django handles the filtering inside the QuerySet, the database does all the heavy lifting and only returns the rows the user is allowed to see. This avoids loading unnecessary data into memory and prevents Python-level filtering after the query has already returned. Everything happens in one optimized SQL call. It also reduces duplication. Instead of repeating the same access logic in multiple views or serializers, the rule stays in one place. Each time I call Model.objects.for_user(user), the correct branch restrictions are automatically applied. It’s cleaner, harder to misuse, and much easier to maintain as the project grows. Another key improvement I added is allowing company owners to block or revoke a user’s access to any branch at any moment. Once access is removed or rejected, the queryset instantly stops returning data from that branch for the user. No extra conditions or special handling required. The model layer enforces the rules consistently. Overall, this pattern makes the system more secure, more performant, and much easier to scale. Sometimes the best improvements come from placing logic exactly where it belongs. #django #python #backend #softwareengineering #webdevelopment #databaseoptimization #performance #cleanarchitecture #scalability

🚀 Day 8 of #30DaysOfDjango – Models & ORM Magic! 🧠💾 Hey Django Ninjas 👋 Yesterday, we mastered *Template Inheritance* and made our front-end cleaner and smarter! 🎨 But websites aren’t just about beautiful pages — they need *data* to come alive! ⚡ Today, we dive into Django’s powerhouse: *Models & ORM (Object-Relational Mapping) 🧩 💡 What’s a Model? It’s the blueprint of your database — defining the structure of your data (like tables). 💡 What’s ORM? ORM lets you interact with your database using *Python code* instead of raw SQL. No messy queries — just clean, readable Django syntax! 😎 🔥 Example: python from django.db import models class Student(models.Model):   name = models.CharField(max_length=100)   age = models.IntegerField()   course = models.CharField(max_length=50) ⚙ Run the Magic Commands: python manage.py makemigrations   python manage.py migrate Boom 💥 — your database is ready to roll! 🎯 Next up (📅 Day 9): We’ll bring data to life in your web pages with Django Admin & QuerySets! #Django #30DaysOfDjango #PythonDeveloper #WebDevelopment #DjangoModels #ORM #DatabaseDesign #BackendDevelopment #LearnToCode #PythonProgramming #TechWithPython #BuildWithDjango #CodeNewbie #DeveloperCommunity #CleanCode #WebDev

🚀 *Day 8 of #30DaysOfDjango – Models & ORM Magic! 🧠💾* Hey Django Ninjas 👋 Yesterday, we mastered *Template Inheritance* and made our front-end cleaner and smarter! 🎨 But websites aren’t just about beautiful pages — they need *data* to come alive! ⚡ Today, we dive into Django’s powerhouse: *Models & ORM (Object-Relational Mapping)* 🧩 💡 *What’s a Model?* It’s the blueprint of your database — defining the structure of your data (like tables). 💡 *What’s ORM?* ORM lets you interact with your database using *Python code* instead of raw SQL. No messy queries — just clean, readable Django syntax! 😎 🔥 *Example:* python from django.db import models class Student(models.Model): name = models.CharField(max_length=100) age = models.IntegerField() course = models.CharField(max_length=50) ⚙ *Run the Magic Commands:* python manage.py makemigrations python manage.py migrate Boom 💥 — your database is ready to roll! 🎯 *Next up (📅 Day 9):* We’ll bring data to life in your web pages with **Django Admin & QuerySets! graphical user interface image dedo related to this caption and make post for linkdin

🚀 Django Day 35 — Understanding BLANK vs NULL + Updating & Deleting Data 🔍📚 Yesterday, while updating my models, I had to set null=True for one of the new fields. Today, I discovered that there’s also blank=True, so I decided to properly understand the difference between the two 🧠✨ Here’s what I learnt: 🔹 null=True This tells Django that if no value is provided, the database should store a NULL value. It affects the database level. 🔹 blank=True This tells Django that this field is allowed to be empty when submitting data through a form. It affects form validation, not the database. After clearing that up, I practised how to update and delete data directly from the Django shell. I assigned an object to a variable, updated its fields using dot notation, and then saved it ✔️. I also tested deleting a record to see how it works. All of this was done inside the interactive console opened with: “python manage.py shell” 🖥️⚡ Not gonna lie, today wasn’t my smoothest day in the terminal 😅— small mistakes kept slowing me down and stressing me out. But like I always say: ✨ Consistency and resilience are what turn frustration into mastery. Keep pushing. 💪🔥 There’s a video below showing some parts of today’s work 🎥👇 #Django #Python #Models #BlankVsNull #Database #Shell #BackendDev #WebDevelopment #LearningJourney #100DaysOfCode #LexissLearns 🚀📘

🌟 **Strengthening My Foundations Before Diving Deeper into Django ORM** As part of my ongoing Django learning journey, I’ve reached one of the most powerful features of the framework — the **Object Relational Mapping (ORM)** system. Before moving ahead, I decided to revisit my **SQL fundamentals**, and it has proven to be extremely valuable. A strong understanding of SQL helps in better interpreting how Django ORM interacts with the database, making queries more intuitive and debugging much easier. 🔍 **Key SQL Concepts I am revising:** * Database fundamentals (Tables, Columns, Primary & Foreign Keys) * CRUD operations (SELECT, INSERT, UPDATE, DELETE) * WHERE, ORDER BY, GROUP BY, HAVING * Joins (INNER, LEFT, RIGHT, FULL) * Constraints (UNIQUE, NOT NULL, CHECK) * Aggregate functions (COUNT, SUM, AVG, MIN, MAX) * Indexes & Query Optimization basics * Relationships between tables Revisiting these essentials is helping me build a stronger foundation to fully leverage Django ORM’s capabilities such as model relationships, querysets, filters, lookups, and aggregations. 📘 Excited to continue my learning journey and strengthen my backend development skills. #Django #Python #WebDevelopment #LearningJourney #SQL #DjangoORM #BackendDevelopment #Programming #TechSkills #SoftwareEngineering #DevelopersJourney #Upskilling

🚀 Django Day 32 — Understanding Migrations ⚙️🧩 Today I learnt about one of Django’s key database features — Migrations. But before that, I discovered that the code I wrote yesterday inside the models.py file wasn’t being recognized by Django 😅. After checking, I realized I forgot to add my app to the INSTALLED_APPS section in the settings.py file. Once I fixed that, everything started working properly. Migrations are basically a way for Django to define and execute steps that modify or update the database whenever I make changes in my models. So whenever I create or edit a model, I need to create and run migrations to apply those changes to the actual database. I created a migration by running the command “python manage.py makemigrations”, and immediately, a new file appeared in the migrations folder called “0001_initial.py”. This file contained some auto-generated code that describes the operations Django should perform on the database. Next, I ran another command, “python manage.py migrate”, which told Django to go through all migration files (including the built-in apps) and execute them. This process created a new database file named “db.sqlite3” — although I can’t open it directly because it’s stored in a binary form. Today’s session helped me understand how Django connects my Python-defined models to a real database using migrations — making everything feel more automated and professional 💻🗄️ #Django #Python #Migrations #SQLite #Database #BackendDevelopment #WebDevelopment #100DaysOfCode #LexissLearns 🚀