Am trying to create simple blog using django.
At first,i created database with the command
python manage.py syncdb
when i try to save blog post,i get the following error
DatabaseError: table blog_app_post has no column named body
models.py code :
from django.db import models
from taggit.managers import TaggableManager
class Post(models.Model):
title = models.CharField(max_length=255)
body = models.TextField()
created = models.DateTimeField()
tags = TaggableManager()
def __unicode__(self):
return self.title
but the column named body is actually created in the Db.
BEGIN;
CREATE TABLE "blog_app_post" (
"id" integer NOT NULL PRIMARY KEY,
"title" varchar(255) NOT NULL,
"body" text NOT NULL,
"created" datetime NOT NULL
)
what does this error mean and anyone would propose a solution for this?
This is probably because you changed the structure of your posts data structure. What you need to do now is delete the schema for your previous table and paste in the new one.
You can avoid problems like this by using migration managers like south.
So, in order to solve this, run manage.py sql <app_name>, then you simply copy the latest SQL table on the list, the first one that is printed. Then you simply maange.py dbshell and then just paste and run the SQL.
How do you say that it's created, you checking it using python manage.py sqlall?
Did you add field body after running syncdb initially. In that case you will have to use a migration.
Related
I have a Django application with a My-SQL database. recently I alter the table_name with the help of MySQL query in the MySQL-shell, after this when I run makemigration and migrate command terminal says "No changes detected". how can i resolve this issue and create again this table with help of Django makemigration and migrate?
can I delete a table from MySQL, any possibility will Django create it again?
If you renamed your table outside Django - you will have to tell Django the new table name like so (using the Meta class):
class Model(models.Model):
name = models.CharField(max_length=255)
class Meta:
db_table = 'new_table_name'
To re-create your table using existing model you need to reset migration for that app to zero and then run migration again
python manage.py migrate APP_NAME zero
python manage.py migrate APP_NAME
It's because the migrations table managed by django doesn't reflect the correct db schema since it was already modified outside of django. If you don't have any important data you can do a migration rollback or recreate the table by hand.
The best way to dela with this is to rename your table back to the original name. Then create a blank migration inside your app and recreate the sql commands you did in the shell inside that migration file. That way django can keep track of the database schema.
You should change the name of the table in models.py not in MySQL shell.
From
class MyModel(models.Model):
...
To
class ThisModel(models.Model):
...
Or Create Proxy Model :
class ThisModel(MyModel):
class Meta:
proxy = True
verbose_name = "ThisModel"
I am using Django models to create a PostgreSQL-DB. I have a DateTimeField where I would like to set the current timestamp as default value. I am aware of multiple sources suggesting how to do this. However, when I inspect my DB outside of Django, the default timestamp doesn't show up.
Approaches I have tried:
1.
created_at = models.DateTimeField(auto_now_add=True)
from django.db.models.functions import Now
...
created_at = models.DateTimeField(default=Now())
from django.utils.timezone import now
...
created_at = models.DateTimeField(default=now)
What I would expect is for the PostgreSQL database to show:
TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP
What It shows is timestamp with time zone not null but no default value. Any ideas on how to do that would be greatly appreciated.
However, when I inspect my DB outside of Django, the default timestamp doesn't show up.
That is correct, Django itself manages the default values. Not the database, Django also manages the ON DELETE trigger, not the database. This gives more flexibility. For example you can pass a callable to the default like you did with default=now. This callable can perform sophisticated actions to determine the default value like making extra queries, API calls, file I/O, etc. This is not possible with a default at the database side.
You can make a data migration file and manually alter the table. You can initialize a data migration with:
python manage.py makemigrations --empty app_name
next you can alter the file it has generated and specify a default with:
# Generated by Django 3.1 on 2020-12-16 17:14
from django.db import migrations
class Migration(migrations.Migration):
dependencies = [
('app_name', 'migration_name'),
]
operations = [
migrations.RunSQL(
'ALTER TABLE table_name ALTER COLUMN created_at SET DEFAULT CURRENT_TIMESTAMP';
)
]
The advantage of doing this is that Django manages the migrations, and it will thus migrate the databases that have not been migrated and thus add a default value.
How can I create a Django REST Framework API that connects to an already existing MySQL tables instead of creating them through modela.py. My models.py shows something like this:
class Author(models.Model):
first_name = models.CharField(max_length=20)
last_name = models.CharField(max_length=20)
def __str__(self):
return f'{self.first_name} {self.last_name}'
Instead of this, I need to take data directly from existing tables in MySQL.
For that you need to define same class name as your table name with meta char field
like for example
RandomTable(id INT(10),name varchar(10)) is your existing mysql table then the models.py for it will be
class AppnameRandomTable(models.Model)
id = models.CharField(db_column="id") #name of column of existing db
inside that you will need to write the fields of your existing table name in meta section
class Meta:
db_table = "RandomTable" #your existing mysql table name
time saving hack just create a class in models.py and on terminal run "python manage.py inspectdb" you will automatically get all the column names from there.
You can just copy and paste names from there , because for reading and writing on columns you need to define their variables in your class even if the table is existing mysql table
python manage.py inspectdb > models.py
If you run that command it will create a models.py in the project's root directory. Once you've done that you can either move it directly into the project or create a models folder and break it down into areas of concern from there. You will likely have to do the work of adding related_name = 'foo' to a lot of fields that have relationships with other models. That can be time-consuming but it works.
I'm learning Django from Tango with Django but I keep getting this error when I type:
python manage.py makemigrations rango
python manage.py migrate
This is the output:
django.db.utils.IntegrityError: UNIQUE constraint failed: rango_category__new.slug
Models.py:
from django.db import models
from django.template.defaultfilters import slugify
class Category(models.Model):
name = models.CharField(max_length=128, unique=True)
views = models.IntegerField(default=0)
likes = models.IntegerField(default=0)
slug = models.SlugField(unique=True)
def save(self, *args, **kwargs):
self.slug = slugify(self.name)
super(Category, self).save(*args, **kwargs)
def __unicode__(self):
return self.name
class Page(models.Model):
category = models.ForeignKey(Category)
title = models.CharField(max_length=128)
url = models.URLField()
views = models.IntegerField(default=0)
def __unicode__(self):
return self.title
The reason for this constrain could be that you didn't have any field called slug in Category class when you have initially migrated it (First Migration), and after adding this field in the model, when you ran makemigrations, you have set default value to something static value(i.e None or '' etc), and which broke the unique constrain for the Category's table's slug column in which slug should be unique but it isn't because all the entry will get that default value.
To solve this, you can either drop the database and migration files and re-run makemigrations and migrate or set a unique default value like this:
slug = models.SlugField(unique=True, default=uuid.uuid1)
Edit:
According to Migrations that add unique fields, modify your migration file to overcome unique constrain. For example, modify your migration file (which added the slug field to the model) like this:
import uuid
from app.models import Category # where app == tango_app_name
class Migration(migrations.Migration):
dependencies = [
('yourproject', '0003_remove_category_slug'),
]
def gen_uuid(apps, schema_editor):
for row in Category.objects.all():
row.slug = uuid.uuid4()
row.save()
operations = [
migrations.AddField(
model_name='category',
name='slug',
field=models.SlugField(default=uuid.uuid4),
preserve_default=True,
),
migrations.RunPython(gen_uuid),
migrations.AlterField(
model_name='category',
name='slug',
field=models.SlugField(default=uuid.uuid4, unique=True),
),
]
I got a field with attribute unique, which was not unique [eg 2-time same value]
python3 manage.py migrate --fake
then
python3 manage.py makemigrations
python3 manage.py migrate
this did the trick
This means a slug should be unique. You may have some data in your model. You need to delete all the data in that model and you need to migrate again.
In this situation, you have two ways to fix the error;
You need to delete it from the Django admin site. More often than not, it may give an error when you are trying to open the model.
Open command prompt
move to project -> py manage.py shell -> from yourappname.models import modelname -> modelname.objects.delete()
Here if you define a product manager for your model. Then you have to define a delete function. Later you should makemigrate, migrate and continue with the second way
I just met this simiilar error: Django UNIQUE constraint failed. I tried examine the code for very long time, but didn't solve it. I finally used SQLiteStudio to examine the data, and found the data is problematic: I unintentionally added two SAME instances which violates the UNIQUE constraint. To be frank I haven't thought the error could be this naive and simple, and because so it took me a lot of time to find out!
I had the same problem and tried all the suggested answers. What finally worked for me was, after I defined the slug field as a URL in models, and ran the makemigrations. I edited the file in makemigrations adding a random number at the end of a basic URL, like this
Generated by Django 3.2.3 on 2022-02-02 20:58
from django.db import migrations, models
from random import randint
class Migration(migrations.Migration):
dependencies = [
('blog', '0002_remove_post_slug1'),
]
operations = [
migrations.AddField(
model_name='post',
name='slug',
field=models.URLField(blank=True, default='http:/salpimientapa.com/' + str(randint(100000,999999))),
),
]
After I ran
python manage.py migrate
I edit the slug as a SlugModel and ran the makemigrations and migrate again
What worked for me was going to the admin and changing the value of duplicate slug, before running the migrations again.
Just delete the last migration in the migration folder
Then run
python manage.py makemigrations
python manage.py migrate
I faced the same issue and solved by populating my slugfied thro' the admin with unique values and without leaving any of them blank.
Basically: You add the field without unique=true in one operation, make a data migration that generates the correct shortuuids for you, and then change the field too unique again.
i have this error too ,
i did delete my database in djangoProject ( for example db.sqlite3 )
and then run
python manage.py makemigrations
python manage.py migrate
It's an Integrity Error probably because the migration will temper with the already exiting data in the database.
I had this error and here's what I did:
Enter in the project folder directory
Open the python interpreter
py manage.py shell
Import your Models
from yourappname.models import model
Delete existing data records in the model
model.objects.all().delete()
Exit the Python Interpreter
exit()
.
Another thing you could do is to set unique="false" on the affecting field. I think this should work; not so sure.
Seems like this should be "easy" or at least documented somewhere, I just cant find it.
Lets say I have a model:
class A(models.Model):
users = models.ManyToMany('auth.User', blank=True)
Now I want to migrate to have a through table to add fields to the ManyToMany relation...
class AUsers(models.Model):
user = models.ForeignKey('auth.User')
a = models.ForeignKey('A')
new_field = models.BooleanField()
class A(models.Model):
users = models.ManyToMany('auth.User', blank=True, through='AUsers')
Then I do:
% ./manage.py schemamigration app --auto
Not totally surprising, it tells me it is going to drop the original auto-created through table and create a new one for AUsers. What's the best practice at this point? Is there a decent way to migrate to the new through table? Do I use db_table in Meta? Do I just not use the through=... right away... then do a schemamigration --auto, then a datamigration to copy the current table (somehow, not sure...) and then add the through relation and let it kill the table?
What's the trick here? Is this really that hard?
You should be able to do this pretty easily.
First of all, make sure that the manual through table that you are creating has the same table name in the database as the one Django originally created automatically.
So, first, let's consider a manual through model before your change:
class AUsers(models.Model):
user = models.ForeignKey('auth.User')
a = models.ForeignKey('A')
class Meta:
db_table = 'appname_a_user'
That should be functionally (almost) identical to the ManyToManyField you used to have. Actually, you could make an empty migration and apply it, and then use --auto for your changes (but don't).
Now, add your field like you did in your sample code above, and then run ./manage.py schemamigration appname manual_through_table --empty. That will give you an empty migration named ####_manual_through_table.py.
In the migration itself, there will be a forwards and backwards method. Each one needs to be one line each:
def forwards(self, orm):
db.add_column('appname_a_user', 'new_field', self.gf('django.db.models.fields.BooleanField')(default=False))
def backwards(self, orm):
db.delete_column('appname_a_user', 'new_field')
That should get you what you are after.
If anyone comes across this question when trying to do the same thing with the moderns migration framework, here are the steps:
Create a new model class that exactly matches the built-in through table
Use the Meta class to set the table name to match the existing table
Generate a migration, which will create the new table and set it as the through for the field.
Without running that migration, edit it to wrap it in a migrations. SeparateDatabaseAndState migration, where the auto-generated steps are in the state_operations field and the database operations are empty.
Modify your through table, as required, making sure to generate new migrations as normal.
As mentioned in a comment, the first step may be simplified using db.rename_table as described here, which gives this through model:
class AUsers(models.Model):
user = models.ForeignKey('auth.User')
a = models.ForeignKey('A')
class Meta:
unique_together = (('user', 'a'),)
Then, create a migration with --auto (this way you'll have the names of the DB tables visible), and replace the content with:
class Migration(SchemaMigration):
def forwards(self, orm):
db.rename_table('appname_a_user', 'appname_auser')
def backwards(self, orm):
db.rename_table('appname_auser','appname_a_user')
I just applied it in my project without issues.