Introduction

In Django, cloning a model instance usually means creating a new row with most of the same field values as an existing row. The simplest technique is to clear the primary key, mark the instance as new, and save it again. That works for the base object, but related fields, unique constraints, and many-to-many relationships need extra handling.

The Basic Clone Pattern

For a normal model instance, the core trick is:

• load the original object
• set pk to None
• set the internal state to adding mode
• save the object

1from blog.models import Article
2
3original = Article.objects.get(pk=1)
4original.pk = None
5original._state.adding = True
6original.save()

After this, original refers to a newly saved database row with a new primary key.

This is the standard answer for cloning a simple Django model instance.

Why This Works

Django decides between INSERT and UPDATE partly from the primary key and the model state. Once pk is None and _state.adding is True, Django treats the instance as a new object to insert rather than an existing one to update.

That is the important internal behavior behind the cloning pattern.

Handle Unique Fields Explicitly

The basic pattern copies all the normal field values, which means unique fields can immediately cause integrity errors.

For example, if your model has a unique slug, you cannot save a clone with the same slug unchanged.

1original = Article.objects.get(pk=1)
2original.pk = None
3original._state.adding = True
4original.slug = f"{original.slug}-copy"
5original.save()

Any field constrained by unique=True or a unique index should be reviewed before saving the clone.

Many-to-Many Fields Need a Second Step

Many-to-many relationships are not copied by the initial save, because the new object must exist in the database first.

1original = Article.objects.get(pk=1)
2original_tags = list(original.tags.all())
3
4original.pk = None
5original._state.adding = True
6original.slug = f"{original.slug}-copy"
7original.save()
8original.tags.set(original_tags)

This two-step pattern is the normal way to clone the base object and then reattach many-to-many relations.

Foreign Keys Usually Stay Referenced

Foreign keys are copied as field values, which means the cloned object still points to the same related objects unless you change them.

That is often correct. For example, duplicating a blog post draft may still point to the same author.

But if the cloning semantics require duplicating related child rows too, that becomes a larger application-level cloning workflow rather than a one-line model copy.

A Safer Helper Function

1def clone_article(article):
2    original_tags = list(article.tags.all())
3
4    article.pk = None
5    article._state.adding = True
6    article.slug = f"{article.slug}-copy"
7    article.save()
8    article.tags.set(original_tags)
9
10    return article

A helper like this makes the cloning behavior explicit and gives you one place to handle uniqueness rules and relationship copying.

Common Pitfalls

The most common mistake is clearing the primary key but forgetting that unique fields may still prevent saving the clone.

Another issue is assuming many-to-many relations will be duplicated automatically on the first save. They will not.

Developers also sometimes mutate the original loaded instance and then keep using it as if it still represented the original row. After cloning, that variable now points to the new object state.

Finally, if cloning semantics are business-critical, do not rely on a one-line copy without documenting which related objects are shared and which are duplicated.

Summary

• The basic Django clone pattern is pk = None, _state.adding = True, then save().
• Review unique fields before saving the clone.
• Copy many-to-many relationships after the new row has been saved.
• Foreign keys usually remain pointed at the same related objects unless you change them.
• Treat cloning as application logic, not only as a database trick, when related objects and uniqueness rules matter.