Python
Object-Oriented Programming
Class
Programming Error
Debugging

Class has no objects member

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Introduction

In Python web projects, the message that a class has no objects member usually points to Django, not to a generic object-oriented programming problem. In Django, objects is the default model manager added to database model classes. If it is missing, the class is usually not a normal Django model, or the manager has been renamed or removed.

What objects Means in Django

For a normal Django model, objects is the default manager used to start database queries.

python
1from django.db import models
2
3
4class Book(models.Model):
5    title = models.CharField(max_length=200)
6
7
8books = Book.objects.all()
9print(books)

This works because Book is a concrete subclass of models.Model, and Django automatically adds the default manager if you do not declare one yourself.

Common Reason 1: The Class Is Not a Django Model

If the class does not inherit from models.Model, Django does not attach an ORM manager.

python
1class Book:
2    title = "Example"
3
4
5# This will fail:
6# Book.objects.all()

That class is just plain Python. It has no database behavior, so objects does not exist.

Fix:

python
1from django.db import models
2
3
4class Book(models.Model):
5    title = models.CharField(max_length=200)

If you want ORM queries, the class must be a real model.

Common Reason 2: The Manager Was Renamed

Django only guarantees a default objects manager if you do not define a differently named manager yourself.

python
1from django.db import models
2
3
4class Person(models.Model):
5    name = models.CharField(max_length=100)
6    people = models.Manager()

Now this is valid:

python
Person.people.all()

But this raises an error:

python
Person.objects.all()

Because the manager name is now people, not objects.

Common Reason 3: You Are Using an Abstract Base Model

Abstract models are templates for other models. They are not concrete tables and are not queried directly.

python
1from django.db import models
2
3
4class TimeStampedModel(models.Model):
5    created_at = models.DateTimeField(auto_now_add=True)
6
7    class Meta:
8        abstract = True

Trying to query TimeStampedModel.objects is conceptually wrong, because Django never creates a table for that abstract base class.

Instead, query the concrete subclass:

python
1class Article(TimeStampedModel):
2    title = models.CharField(max_length=200)
3
4
5Article.objects.all()

Common Reason 4: Using objects on an Instance Instead of the Class

Managers belong on the model class, not on an individual instance.

Wrong:

python
book = Book(title="Django")
# book.objects.all()

Correct:

python
Book.objects.all()

This distinction matters because the manager represents table-level query access, not instance behavior.

A Good Way to Debug It

When you hit this error, check three things immediately:

python
print(Book)
print(issubclass(Book, models.Model))
print(hasattr(Book, "objects"))

Then inspect whether you defined a custom manager name instead.

If the class is generated dynamically or imported indirectly, also verify that you are referencing the actual model class you intended, not a serializer, form, or plain helper class with a similar name.

If You Need a Custom Manager

If you want custom query logic, keep a manager on the model explicitly.

python
1from django.db import models
2
3
4class PublishedManager(models.Manager):
5    def published(self):
6        return self.filter(is_published=True)
7
8
9class Post(models.Model):
10    title = models.CharField(max_length=200)
11    is_published = models.BooleanField(default=False)
12    objects = PublishedManager()

Now Post.objects.published() works, and objects still exists.

Common Pitfalls

  • Calling .objects on a plain Python class that is not a Django model.
  • Renaming the manager to something like people and still expecting objects to exist.
  • Querying an abstract base model directly.
  • Accessing .objects on a model instance instead of the model class.
  • Importing the wrong class with the same or similar name from another module.

Summary

  • In Django, objects is the default model manager for concrete model classes.
  • If it is missing, the class is often not a real model or the manager has a different name.
  • Abstract models and plain Python classes do not behave like queryable ORM models.
  • Managers live on the class, not on instances.
  • Check inheritance, manager names, and imports before assuming the ORM is broken.

Course illustration
Course illustration

All Rights Reserved.