So some time a couple migrations after my first one, I decided I wanted to include these fields:
created = models.DateTimeField(auto_now_add=True)
modified = models.DateTimeField(auto_now=True)
into one of my models. When I makemigrations it gave me
You are trying to add a non-nullable field 'created' to episode without a default; we can't do that (the database needs
something to populate existing rows).
So I then changed it to
created = models.DateTimeField(auto_now_add=True, default=datetime.now)
After trying to makemigrations again, it said that at_api.Episode.modified: (fields.E160) The options auto_now, auto_now_add, and default are mutually exclusive. Only one
of these options may be present.
All right, so I just went ahead and removed the auto_now_add
created = models.DateTimeField(default=datetime.now)
I could now makemigrations without any problems. And then I later removed default=datetime.now and replaced it with auto_now_add=True, and migrated again without any problems. However, I can't help feeling that this might not be the best way of doing things. I feel like something might go wrong later in the project.
I think the best practice here would have been to make the fields nullable. What your created field means at the moment is: "The time when the instance was created, or the arbitrary time when I ran the migration." The standard way to represent the lack of a value is NULL, rather than an arbitrary value.
That said, if you do want to use some arbitrary value you just need to tell Django what it is. Usually makemigrations gives you the option to indicate a one-off value to use for existing rows - did that not happen?
A more laborious method would be to declare the field nullable, then create a data migration to fill in your desired value, and then make it non-nullable. What you did is basically a simplified version of that. I don't see it creating any problems moving forward other than the issue of created not really being the time the instance was created.
I've just had the exact problem. I use Django 1.10. I read Kevin answer and I've tried to put default value when Django asked me to fill it as datetime.now string.
And I was surprised because, for those fields, Django automatically ask you if you want to use datetime.now as default:
$ ./manage.py makemigrations
You are trying to add the field 'date_created' with 'auto_now_add=True' to projectasset without a default; the database needs something to populate existing rows.
1) Provide a one-off default now (will be set on all existing rows)
2) Quit, and let me add a default in models.py
Select an option: 1
Please enter the default value now, as valid Python
You can accept the default 'timezone.now' by pressing 'Enter' or you can provide another value.
The datetime and django.utils.timezone modules are available, so you can do e.g. timezone.now
Type 'exit' to exit this prompt
[default: timezone.now] >>>
So, I just confirm that and everything seems to be working fine!
Related
I learned Django recently. Now on one of the projects I'm working on, I need to add a new field, is_core_administrator to model UserProfile, which will set the oldest user as a core administrator. I need to update this field for all users with migration.
Is there a way to do this? I mean, when I make migrations, is it possible to update this field to true for the ​oldest user, and false for rest. Finding the oldest user will not be difficult since we already have another field DateJoined. I just want to update the corresponding field on making the migration.
Sure, just use migrations.RunSQL or migrations.RunPython depending on your requirements.
The latter could be easier to use in this case, but you should be able to do this with a single UPDATE SQL statement too.
You could do that using RunPython option in Django migrations.
Create a function at the top of the migration file.
def set_default_values(apps, schema_editor):
# Set the defualt values
Add the below line before the alter field operation in the migration file.
RunPython(set_default_values)
Please clarify your use case. I see that you have three options:
You might need migrate command to perform this modification every time you migrated your program. If this is so, you need to add a small loop to the end of the script that would be generated by makemigrations and if you ship your program to the production environment with the modified migration script you will be able to do so.
If you need this as a one time only modification for your development environment, I suggest it is better not to modify migration script but to change is_core_administrator by using Django shell manually.
If you need to program to set its first created UserProfile with is_core_administrator set True where and when ever installed, I suggest the easiest way is to define save(self): and to check within if the object you are going to save is the first instant probably by using UserProfile.objects.count() or UserProfile.objects.exists() and set is_core_administrator accordingly. Maybe something like following:
class UserProfile(models.Model):
...
...
is_core_administrator=models.BooleanField(default=False)
def save(self, force_insert=False, force_update=False, using=None,
update_fields=None):
if not UserProfile.objects.exists():
self.is_core_administrator=True
self.etiket=self.woo_name
return models.Model.save(self, force_insert=force_insert, force_update=force_update, using=using, update_fields=update_fields)
// don't delete database entries but set the newly added attribute deletedAt
// to the current date (when deletion was done). paranoid will only work if
// timestamps are enabled
paranoid: true,
I used Sequelize.js ORM, and there was option paranoid like above description. (from Sequelize.js tutorial docs)
I want to make my Django Model paranoid.
I googled with keywords like "django paranoid", but i couldn't find informations. What is a general name for the option "paranoid" and how can i make my django model act like the option?
Or should I make mixins or middlewares to make paranoid?
of course, you can use django-paranoid
this library will add deleted_at, updated_at and created_at field, also a soft delete method.
You only need extend to model with ParanoidModel.
For see the deleted object you can use objects_with_deleted:
MyModel.objects_with_deleted.last()
and if do you want do hard delete an object you only should use True param:
m = MyModel.objects.last()
m.delete(True)
So, in a bit more detail I have a model with a field like: permalink = models.IntegerField(default=0)
I've not actually been using this field - but would now like to.
However, it seems all models on this table, permalink is now 57295730 - on all 2000 models!
In an attempt to debug, I tried completly wiping the DB, running migrate (~100 migrations) - but then creating a instance of the model, I am told permalink violates the not-null constraint though I am definitely passing it a value! I also get a list of the values I am passing it, but am not sure how to know which value/column relates to which field?
I've even tried removing DB, removing migrations, running a new makemigrations - and still get the null violation...
even stranger, it looks like this field has not been touched since the initial migration!
migrations$ egrep permalink *
0001_initial.py: ('permalink', models.IntegerField(default=0)),
migrations$
I'm running (k)ubuntu 14.04, postgres 9.3, python 3.4, django 1.9.4
Though I'd love to know how to fix this - my question is really "What can I do to debug this kind of situation?"
Well Not the answer I want - but a working answer:
do automated testing
use CI! Prevent this problem in the first place
And if you are not doing the above...
use git bisect (or if you cant, manually use git reset --hard HEAD~1 to find the problem!)
in mycase, I was over-riding the save function of the model in a... stupid way!
edit:
in a little more detail, I was setting permalink to be 1 greater than the current biggest value - but in an earlier commit, had removed the + 1
However, I did not notice this error quickly, as it did not happen with data in the DB.
So! the error was actually quite informative - had I been running my tests more often (or using CI) I would have been informed of the error instantly, and saved myself quite a headache!
so, in short: **write tests, run them - automatically **
I am trying to add a new field to a model - normally a simple process. On one model, I get an error (adding the same field to a different model in the same app causes no problems at all).
The field:
mediumlink = models.URLField(max_length=500, null=True)
Although, any field type or name has the same error.
The error, when using makemigrations:
django.db.utils.ProgrammingError: column images_locationimage.mediumlink does not exist
LINE 1: ...."imagelink", "images_locationimage"."thumblink", "images_lo...
^
I'm stumped! Any help would be awesome.
There are certain files that Django has to have in a working state before it can do other things -- particularly, I think, where models and views are defined (not sure exactly and the list is much shorter with Django 1.7). In any case, if you reference your change before the migration is made and applied, you can find yourself in a catch-22 of needing the migration before you can make the migration. Always get your database in order first before you start using your changes. (In your case, commenting out the offending code will let you proceed with the migration, then quickly get back to where you were.)
I have a Django web site running a mini CMS we've built internally years ago, it's using postgresql. When saving a simple title and a paragraph of text I get the following error:
value too long for type character varying(100)
The weird thing is, not a single column is varying(100) they are all 200 or 250, even the default Django ones have been changed from the 100 to 200 due to a re-opened ticket mentioned here
Does anyone know of a solution to this problem?
I can bet money you have a models.SlugField without length set. The default length is 50 characters, most likely it's not enough for your use case.
Change it to models.SlugField(max_length=255) and migrate your database schema.
I also had this problem when using a filefield and was scratching my head for a while. Of course the default FileField instances are created with a 100 character limit.
https://docs.djangoproject.com/en/dev/ref/models/fields/#filefield
This is an error message from Postgres and not django.
You seem to have changed the length of the field in the models.py, but that doesn't change the database length which was created when you did a manage.py syncdb.
You have to alter the length of the field in the database, directly.
Django 2.1
I encountered this problem while switching from sqlite3 to postgresql.
Remove the migration files in each app's migrations folder except __init__.py
Then re-run migration
(venv)myapp$python manage.py makemigrations
(venv)myapp$python manage.py migrate
(venv)myapp$python manage.py runserver
I had a similar problem with django-autoslugfield
I was using a similar package and then switched over to django-autoslugfield
I was getting this error:
value too long for type character varying(50)
despite the fact that my models.py had:
slug = AutoSlugField(max_length=255, populate_from='name', unique=True)
and in my db the it the type was
character varying 255
once i remove max_length=255 from the field i.e.
slug = AutoSlugField(populate_from='name', unique=True)
then it worked fine
i went through this same error. and when i made changes in the modele, i kept having the same error.
Here is how i fixed it.
It might be necessary to skip few migrations for the program to only use the migration where changes have been made for the CharField max_lenght.
for that you have to run
python manage.py showmigrations
to see which migrations have not been made.
then you skip them until you get to the last with the command
python manage.py migrate <app> 000_migration_number --fake
I realize the question is already answered but for others that come here when looking for the error message:
In my case the problem was that my table name exceeded 50 characters. Apparently this is not allowed. Changing the table name solved the problem.
Read more here: https://code.djangoproject.com/ticket/18959
Michael Samoylov's answer pointed me in the right direction. I had the same error come up, except it was with a FileField.
Fields have a max_length, even if you have not explicitly set a max_length. Increase the value so that your data fits to avoid the error.
In my case, the data was too large to reasonably store in the database. I resorted to saving my file to disk, then saving the file path in the database.
I had this problem when I wanted to set max_length to a lower value on a FileField.
Interestingly, the error message states value too long but in my case the value was too short.
The solution was to set back the max_length to its old value. It's quite weird that the migration couldn't be done.
I also had to delete the wrongly generated migrations files and rerun python manage.py makemigrations and python manage.py migrate.
If it's not SlugField, FileField, or any other field mentioned here--scroll back to where the migration got stuck in the terminal. For me it was AddField
Good talk.
First, try setting max_length to something reasonable on all applicable field types in your model.
For example: MyText = models.CharField(max_length=2000)
If you don't set a max_length, your database might be applying a default max_length, shorter than the length of your input data, causing your value too long for type character error.
If that doesn't work and you started in SQLite and changed databases to PostgreSQL, the previous migrations from SQLite might be interfering with the new PostgreSQL migrations.
Go into the migrations folder for your project and delete the old migration files to get a fresh start. Then try makemigrations and migrate again :)
predefined fields in model.py creates the problem. Extend it to desired length, i think problem will be resolved.
For the FileField and the ImageField, from the Django docs:
FileField instances are created in your database as varchar columns with a default max length of 100 characters. As with other fields, you can change the maximum length using the max_length argument.
The value can be 100 or 25 or 17 whatever , the reason behind that is models , search where you have added that particular length(17,25) and you will get the bug ! ,
You are trying to impose a field length more than mentioned one.
This solved my issue , I hope it will help you too