Develop Reference

Unable to migrate in django

model.py
class Staff(models.Model):
organization = models.ForeignKey(
Organization, related_name='staff_organization', on_delete=models.CASCADE, blank=True)
user = models.OneToOneField(
User, on_delete=models.CASCADE, blank=True)
phone = models.CharField(max_length=15, blank=True)
address = models.CharField(max_length=200, blank=True)
I am trying to add the new field in the database table. II just added the address field. I got following error:
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "manage.py", line 21, in <module>
main()
File "manage.py", line 17, in main
execute_from_command_line(sys.argv)
File "D:\Project\AIT Project\project\venv\lib\site-packages\django\core\management\__init__.py", line 401, in execute_from_command_line
utility.execute()
File "D:\Project\AIT Project\project\venv\lib\site-packages\django\core\management\__init__.py", line 395, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "D:\Project\AIT Project\project\venv\lib\site-packages\django\core\management\base.py", line 328, in run_from_argv
self.execute(*args, **cmd_options)
File "D:\Project\AIT Project\project\venv\lib\site-packages\django\db\backends\base\schema.py", line 142, in execute
cursor.execute(sql, params)
File "D:\Project\AIT Project\project\venv\lib\site-packages\django\db\backends\utils.py", line 100, in execute
return super().execute(sql, params)
File "D:\Project\AIT Project\project\venv\lib\site-packages\django\db\backends\utils.py", line 68, in execute
return self._execute_with_wrappers(sql, params, many=False, executor=self._execute)
File "D:\Project\AIT Project\project\venv\lib\site-packages\django\db\backends\utils.py", line 77, in _execute_with_wrappers
return executor(sql, params, many, context)
File "D:\Project\AIT Project\project\venv\lib\site-packages\django\db\backends\utils.py", line 86, in _execute
return self.cursor.execute(sql, params)
File "D:\Project\AIT Project\project\venv\lib\site-packages\django\db\utils.py", line 90, in __exit__
raise dj_exc_value.with_traceback(traceback) from exc_value
File "D:\Project\AIT Project\project\venv\lib\site-packages\django\db\backends\utils.py", line 86, in _execute
return self.cursor.execute(sql, params)
django.db.utils.ProgrammingError: relation "auth_user_email_1c89df09_uniq" already exists

try to run
python manage.py migrate <yourappname> zero
then go into you migration folder and delete all the file except pycache and initpy
then again
python manage.py makemigrations
python manage.py migrate
this has to solve your problem

One option is to delete auth_user_email_1c89df09_uniq constraint from db in any database management system. i did it with pgadmin 2.

ArrayField of DateTimeField raises "django.db.utils.ProgrammingError: cannot cast type timestamp with time zone to timestamp with time zone[]"

I am building an app in Django.
I created a new (still empty) model having an ArrayField of DateTimeField, defined as follow:
Record_time_values = ArrayField(models.DateTimeField(), blank=False, null=False)
As I run
python manage.py makemigrations
python manage.py migrate
I get
django.db.utils.ProgrammingError: cannot cast type timestamp with time
zone to timestamp with time zone[] LINE 1: ...estamp with time zone[]
USING "Record_time_values"::timestam...
I did a little research and this is the thread that gets closest to my issue, but I don't want to go deep using SQL to fix the problem.
Does not it exist a clean way to fix the problem via pure python / Django?
In alternative, does exist a good way to store an array of DateTimeField inside a model, bypassing the arrayfield?
Complete Traceback:
(met5) C:\Users\Tommaso\Django rest framework\Udemy Django\aqi_luftdaten>python manage.py migrate
Operations to perform:
Apply all migrations: admin, auth, contenttypes, pm_lookup, sessions
Running migrations:
Applying pm_lookup.0003_auto_20200602_1142...Traceback (most recent call last):
File "C:\Applicazioni_Tommaso\Phyton\lib\site-packages\django\db\backends\utils.py", line 84, in _execute
return self.cursor.execute(sql, params)
psycopg2.errors.CannotCoerce: cannot cast type timestamp with time zone to timestamp with time zone[]
LINE 1: ...estamp with time zone[] USING "Record_time_values"::timestam...
^
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "manage.py", line 21, in <module>
main()
File "manage.py", line 17, in main
execute_from_command_line(sys.argv)
File "C:\Applicazioni_Tommaso\Phyton\lib\site-packages\django\core\management\__init__.py", line 381, in execute_from_command_line
utility.execute()
File "C:\Applicazioni_Tommaso\Phyton\lib\site-packages\django\core\management\__init__.py", line 375, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "C:\Applicazioni_Tommaso\Phyton\lib\site-packages\django\core\management\base.py", line 323, in run_from_argv
self.execute(*args, **cmd_options)
File "C:\Applicazioni_Tommaso\Phyton\lib\site-packages\django\core\management\base.py", line 364, in execute
output = self.handle(*args, **options)
File "C:\Applicazioni_Tommaso\Phyton\lib\site-packages\django\core\management\base.py", line 83, in wrapped
res = handle_func(*args, **kwargs)
File "C:\Applicazioni_Tommaso\Phyton\lib\site-packages\django\core\management\commands\migrate.py", line 234, in handle
fake_initial=fake_initial,
File "C:\Applicazioni_Tommaso\Phyton\lib\site-packages\django\db\migrations\executor.py", line 117, in migrate
state = self._migrate_all_forwards(state, plan, full_plan, fake=fake, fake_initial=fake_initial)
File "C:\Applicazioni_Tommaso\Phyton\lib\site-packages\django\db\migrations\executor.py", line 147, in _migrate_all_forwards
state = self.apply_migration(state, migration, fake=fake, fake_initial=fake_initial)
File "C:\Applicazioni_Tommaso\Phyton\lib\site-packages\django\db\migrations\executor.py", line 245, in apply_migration
state = migration.apply(state, schema_editor)
File "C:\Applicazioni_Tommaso\Phyton\lib\site-packages\django\db\migrations\migration.py", line 124, in apply
operation.database_forwards(self.app_label, schema_editor, old_state, project_state)
File "C:\Applicazioni_Tommaso\Phyton\lib\site-packages\django\db\migrations\operations\fields.py", line 249, in database_forwards
schema_editor.alter_field(from_model, from_field, to_field)
File "C:\Applicazioni_Tommaso\Phyton\lib\site-packages\django\db\backends\base\schema.py", line 535, in alter_field
old_db_params, new_db_params, strict)
File "C:\Applicazioni_Tommaso\Phyton\lib\site-packages\django\db\backends\postgresql\schema.py", line 124, in _alter_field
new_db_params, strict,
File "C:\Applicazioni_Tommaso\Phyton\lib\site-packages\django\db\backends\base\schema.py", line 685, in _alter_field
params,
File "C:\Applicazioni_Tommaso\Phyton\lib\site-packages\django\db\backends\base\schema.py", line 137, in execute
cursor.execute(sql, params)
File "C:\Applicazioni_Tommaso\Phyton\lib\site-packages\django\db\backends\utils.py", line 99, in execute
return super().execute(sql, params)
File "C:\Applicazioni_Tommaso\Phyton\lib\site-packages\django\db\backends\utils.py", line 67, in execute
return self._execute_with_wrappers(sql, params, many=False, executor=self._execute)
File "C:\Applicazioni_Tommaso\Phyton\lib\site-packages\django\db\backends\utils.py", line 76, in _execute_with_wrappers
return executor(sql, params, many, context)
File "C:\Applicazioni_Tommaso\Phyton\lib\site-packages\django\db\backends\utils.py", line 84, in _execute
return self.cursor.execute(sql, params)
File "C:\Applicazioni_Tommaso\Phyton\lib\site-packages\django\db\utils.py", line 89, in __exit__
raise dj_exc_value.with_traceback(traceback) from exc_value
File "C:\Applicazioni_Tommaso\Phyton\lib\site-packages\django\db\backends\utils.py", line 84, in _execute
return self.cursor.execute(sql, params)
django.db.utils.ProgrammingError: cannot cast type timestamp with time zone to timestamp with time zone[]
LINE 1: ...estamp with time zone[] USING "Record_time_values"::timestam...

Ok, reproduced. This happens when you alter a column to an array from a normal datetimefield. If you just create the field as an array field with datetimefield, then the problem does not occur.
Since the table is still empty, you should do some migration maintenance and instead of creating the field and then altering it, create it the right way. This may involve rolling back one or more migrations, that may destroy data in other tables. If that's a problem, then you should backup those tables before doing this. See Reversing migrations for details.

Delete operation finding a relationship that doesn't exist

In my multi-tenant site, I have the following database structure:
Public (shared):
tenants
domains
users
Test:
users
clients
projects
projectusers
tasks
Test2:
users
clients
projects
projectusers
tasks
This is a simplified list - all three schemas include (among others) auth_permissions, auth_group, and auth_group_permissions.
The projectusers table (cross-ref that ties users to projects), has a One-to-One field for the User table, and a ForeignKey to the projects table, as follows:
class ProjectUser(DateFieldsModelMixin, models.Model):
user = models.OneToOneField(
User,
on_delete=models.PROTECT,
verbose_name=_('User'),
related_name='user_projects',
)
project = models.ForeignKey(
Project,
on_delete=models.PROTECT,
verbose_name=_('Project'),
related_name='project_users',
)
...other fields omitted...
The point is, the reference from projectusers to users is defined in the ProjectUser model. There's no reference from User model back to ProjectUser.
I wrote a load_fixtures (management) command to, well, load fixtures to set up our dev site(s) with the data we'd need to do preliminary testing (before writing/running unit-tests).
One of the things that command does is empty the auth_permissions table, reset the auto-increment value back to 1, and then import its fixture so that all IDs match across local dev sites, and (eventually) in production. This is necessary because fixtures for auth_group and auth_group_permissions reference permissions by ID.
The error I'm getting occurs during the delete process on that table when running in the "public" schema. Note there is no projectusers table in Public. This is the line that does the delete on auth_permissions:
model.objects.all().delete()
That is line 215 in the load_fixtures command, in the clear_table() method. You can see that line referenced in the traceback:
Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/usr/local/lib/python3.6/site-packages/django/core/management/__init__.py", line 381, in execute_from_command_line
utility.execute()
File "/usr/local/lib/python3.6/site-packages/django/core/management/__init__.py", line 375, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/usr/local/lib/python3.6/site-packages/django/core/management/base.py", line 316, in run_from_argv
self.execute(*args, **cmd_options)
File "/usr/local/lib/python3.6/site-packages/django/core/management/base.py", line 353, in execute
output = self.handle(*args, **options)
File "/code/src/virticl_api/utilities/management/commands/load_fixtures.py", line 148, in handle
self.clear_table(file_path, self.clear_tables[file_name])
File "/code/src/virticl_api/utilities/management/commands/load_fixtures.py", line 215, in clear_table
model.objects.all().delete()
File "/usr/local/lib/python3.6/site-packages/django/db/models/query.py", line 662, in delete
collector.collect(del_query)
File "/usr/local/lib/python3.6/site-packages/django/db/models/deletion.py", line 220, in collect
elif sub_objs:
File "/usr/local/lib/python3.6/site-packages/django/db/models/query.py", line 272, in __bool__
self._fetch_all()
File "/usr/local/lib/python3.6/site-packages/django/db/models/query.py", line 1186, in _fetch_all
self._result_cache = list(self._iterable_class(self))
File "/usr/local/lib/python3.6/site-packages/django/db/models/query.py", line 54, in __iter__
results = compiler.execute_sql(chunked_fetch=self.chunked_fetch, chunk_size=self.chunk_size)
File "/usr/local/lib/python3.6/site-packages/django/db/models/sql/compiler.py", line 1065, in execute_sql
cursor.execute(sql, params)
File "/usr/local/lib/python3.6/site-packages/django/db/backends/utils.py", line 100, in execute
return super().execute(sql, params)
File "/usr/local/lib/python3.6/site-packages/django/db/backends/utils.py", line 68, in execute
return self._execute_with_wrappers(sql, params, many=False, executor=self._execute)
File "/usr/local/lib/python3.6/site-packages/django/db/backends/utils.py", line 77, in _execute_with_wrappers
return executor(sql, params, many, context)
File "/usr/local/lib/python3.6/site-packages/django/db/backends/utils.py", line 85, in _execute
return self.cursor.execute(sql, params)
File "/usr/local/lib/python3.6/site-packages/django/db/utils.py", line 89, in __exit__
raise dj_exc_value.with_traceback(traceback) from exc_value
File "/usr/local/lib/python3.6/site-packages/django/db/backends/utils.py", line 85, in _execute
return self.cursor.execute(sql, params)
django.db.utils.ProgrammingError: relation "projects_projectuser" does not exist
LINE 1: ...ourly_rate", "projects_projectuser"."status" FROM "projects_...
So why is that delete method, running in the Public schema, finding a relationship to the projectuser table?

Django and Redshift inspectdb requires superuser

I keep getting an error with my redshift database, I can't seem to run a ./manage.py inspectdb command on the database.
I did a select * from pg_user, and verified my user was a superuser.
Still not sure why this problem exists, https://forums.aws.amazon.com/thread.jspa?threadID=133514 this is an old link to the problem.
Error:
django.db.utils.ProgrammingError: must be superuser to examine "max_index_keys"
CONTEXT: SQL function "_pg_keypositions" statement 1
The error log:
Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/webapps/hello_django/local/lib/python2.7/site-packages/django/core/mana gement/__init__.py", line 338, in execute_from_command_line
utility.execute()
File "/webapps/hello_django/local/lib/python2.7/site-packages/django/core/mana gement/__init__.py", line 330, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/webapps/hello_django/local/lib/python2.7/site-packages/django/core/mana gement/base.py", line 393, in run_from_argv
self.execute(*args, **cmd_options)
File "/webapps/hello_django/local/lib/python2.7/site-packages/django/core/mana gement/base.py", line 444, in execute
output = self.handle(*args, **options)
File "/webapps/hello_django/local/lib/python2.7/site-packages/django/core/mana gement/commands/inspectdb.py", line 25, in handle
for line in self.handle_inspection(options):
File "/webapps/hello_django/local/lib/python2.7/site-packages/django/core/mana gement/commands/inspectdb.py", line 72, in handle_inspection
constraints = connection.introspection.get_constraints(cursor, table_name)
File "/webapps/hello_django/local/lib/python2.7/site-packages/django/db/backen ds/postgresql_psycopg2/introspection.py", line 187, in get_constraints
""", ["public", table_name])
File "/webapps/hello_django/local/lib/python2.7/site-packages/django/db/backen ds/utils.py", line 79, in execute
return super(CursorDebugWrapper, self).execute(sql, params)
File "/webapps/hello_django/local/lib/python2.7/site-packages/django/db/backen ds/utils.py", line 64, in execute
return self.cursor.execute(sql, params)
File "/webapps/hello_django/local/lib/python2.7/site-packages/django/db/utils. py", line 97, in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
File "/webapps/hello_django/local/lib/python2.7/site-packages/django/db/backen ds/utils.py", line 64, in execute
return self.cursor.execute(sql, params)
django.db.utils.ProgrammingError: must be superuser to examine "max_index_keys"
CONTEXT: SQL function "_pg_keypositions" statement 1

Django syncdb error

I have django.contrib.auth in my installed apps and everything was was working about 10 minutes ago. I deleted the existed database because I had problems with south migrations. When I try to rebuild it I get an error.
Error: django.db.utils.DatabaseError: no such table: auth_user
Traceback (most recent call last):
File "manage.py", line 11, in <module>
execute_manager(settings)
File "/usr/lib/python2.7/site-packages/django/core/management/__init__.py", line 438, in execute_manager
utility.execute()
File "/usr/lib/python2.7/site-packages/django/core/management/__init__.py", line 379, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/usr/lib/python2.7/site-packages/django/core/management/base.py", line 191, in run_from_argv
self.execute(*args, **options.__dict__)
File "/usr/lib/python2.7/site-packages/django/core/management/base.py", line 219, in execute
self.validate()
File "/usr/lib/python2.7/site-packages/django/core/management/base.py", line 249, in validate
num_errors = get_validation_errors(s, app)
File "/usr/lib/python2.7/site-packages/django/core/management/validation.py", line 35, in get_validation_errors
for (app_name, error) in get_app_errors().items():
File "/usr/lib/python2.7/site-packages/django/db/models/loading.py", line 146, in get_app_errors
self._populate()
File "/usr/lib/python2.7/site-packages/django/db/models/loading.py", line 61, in _populate
self.load_app(app_name, True)
File "/usr/lib/python2.7/site-packages/django/db/models/loading.py", line 78, in load_app
models = import_module('.models', app_name)
File "/usr/lib/python2.7/site-packages/django/utils/importlib.py", line 35, in import_module
__import__(name)
File "/home/bruk/workspace/hungryDroid/src/hungryDroid/Ingredient/models.py", line 22, in <module>
class Ingredient(models.Model):
File "/home/bruk/workspace/hungryDroid/src/hungryDroid/Ingredient/models.py", line 26, in Ingredient
FKowner = models.ForeignKey(User, default=User.objects.get(pk=1).id)
File "/usr/lib/python2.7/site-packages/django/db/models/manager.py", line 132, in get
return self.get_query_set().get(*args, **kwargs)
File "/usr/lib/python2.7/site-packages/django/db/models/query.py", line 342, in get
num = len(clone)
File "/usr/lib/python2.7/site-packages/django/db/models/query.py", line 80, in __len__
self._result_cache = list(self.iterator())
File "/usr/lib/python2.7/site-packages/django/db/models/query.py", line 271, in iterator
for row in compiler.results_iter():
File "/usr/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 677, in results_iter
for rows in self.execute_sql(MULTI):
File "/usr/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 732, in execute_sql
cursor.execute(sql, params)
File "/usr/lib/python2.7/site-packages/django/db/backends/util.py", line 15, in execute
return self.cursor.execute(sql, params)
File "/usr/lib/python2.7/site-packages/django/db/backends/sqlite3/base.py", line 200, in execute
return Database.Cursor.execute(self, query, params)
**django.db.utils.DatabaseError: no such table: auth_user**

The problem is that you are running a query against the User model
File "/home/bruk/workspace/hungryDroid/src/hungryDroid/Ingredient/models.py", line 26, in Ingredient
FKowner = models.ForeignKey(User, default=User.objects.get(pk=1).id)
In the syncdb process (during field declaration actually, so any time your module is imported, like during this validation process).
This will make sure that the auth_user query is executed before the auth_user table is created.
A safer way to get the functionality with the default user is to do
def get_default_user():
return User.objects.get(pk=1)
And then in your field declaration, do
FKowner = models.ForeignKey(User, default=get_default_user)
As per the model field reference default can be a callable. Note that you would have the same problem if you used get_default_user() in there - then it executes immediately, not on-demand.