Django-将用户名字段更改为BigAutoField?

时间:2021-04-28 19:22:07

I'm designing an Application where username will be an AutoIntegerField and unique.

我正在设计一个应用程序,其中用户名将是一个AutoIntegerField并且是唯一的。

Here's my model.

这是我的模特。

class ModelA(models.Model):
    username = models.BigAutoField(primary_key=True, db_index=False)
    user_id = models.UUIDField(default=uuid.uuid4, unique=True,
                               editable=False)

Initially, I wanted user_id to be a primary_key, but I can't create an AutoField which is not primary_key. As a result, I'd to let go off user_id as primary_key and assigned username as the primary key.

最初,我希望user_id是primary_key,但是我不能创建不是primary_key的AutoField。因此,我将释放user_id作为primary_key并将用户名指定为主键。

Now, when I run the migrations, it throws an error saying,

现在,当我运行迁移时,它会抛出错误说,

django.db.utils.ProgrammingError: operator class "varchar_pattern_ops" does not accept data type bigint

Complete StackTrace:-

  Applying users.0005_auto_20180626_0914...Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/django/db/backends/utils.py", line 65, in execute
    return self.cursor.execute(sql, params)
psycopg2.ProgrammingError: operator class "varchar_pattern_ops" does not accept data type bigint


The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "manage.py", line 22, in <module>
    execute_from_command_line(sys.argv)
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/django/core/management/__init__.py", line 364, in execute_from_command_line
    utility.execute()
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/django/core/management/__init__.py", line 356, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/django/core/management/base.py", line 283, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/django/core/management/base.py", line 330, in execute
    output = self.handle(*args, **options)
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/django/core/management/commands/migrate.py", line 204, in handle
    fake_initial=fake_initial,
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/django/db/migrations/executor.py", line 115, in migrate
    state = self._migrate_all_forwards(state, plan, full_plan, fake=fake, fake_initial=fake_initial)
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/django/db/migrations/executor.py", line 145, in _migrate_all_forwards
    state = self.apply_migration(state, migration, fake=fake, fake_initial=fake_initial)
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/django/db/migrations/executor.py", line 244, in apply_migration
    state = migration.apply(state, schema_editor)
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/django/db/migrations/migration.py", line 129, in apply
    operation.database_forwards(self.app_label, schema_editor, old_state, project_state)
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/django/db/migrations/operations/fields.py", line 216, in database_forwards
    schema_editor.alter_field(from_model, from_field, to_field)
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/django/db/backends/base/schema.py", line 515, in alter_field
    old_db_params, new_db_params, strict)
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/django/db/backends/postgresql/schema.py", line 112, in _alter_field
    new_db_params, strict,
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/django/db/backends/base/schema.py", line 684, in _alter_field
    params,
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/django/db/backends/base/schema.py", line 120, in execute
    cursor.execute(sql, params)
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/django/db/backends/utils.py", line 80, in execute
    return super(CursorDebugWrapper, self).execute(sql, params)
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/django/db/backends/utils.py", line 65, in execute
    return self.cursor.execute(sql, params)
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/django/db/utils.py", line 94, in __exit__
    six.reraise(dj_exc_type, dj_exc_value, traceback)
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/django/utils/six.py", line 685, in reraise
    raise value.with_traceback(tb)
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/django/db/backends/utils.py", line 65, in execute
    return self.cursor.execute(sql, params)
django.db.utils.ProgrammingError: operator class "varchar_pattern_ops" does not accept data type bigint

1 个解决方案

#1


2  

I think the issue is that you still have an old index on your username field that *es with the new type. The db_index=False argument has no effect because primary_key=True always generates an index.

我认为问题是你的用户名字段上仍然有一个与新类型冲突的旧索引。 db_index = False参数无效,因为primary_key = True始终生成索引。

You might be able to solve this by removing primary_key=True, creating a migration, and then re-adding it and creating another migration. Alternatively, you can do it by hand by dropping and re-creating the index. If you want to go down that path, consult this answer.

您可以通过删除primary_key = True,创建迁移,然后重新添加它并创建另一个迁移来解决此问题。或者,您可以通过删除和重新创建索引来手动完成。如果您想沿着这条路走下去,请参考这个答案。

If your project is still in an early stage and you don't have any valuable data, you can take the easy way out and drop any tables related to your users app or even the complete database, delete all migrations in the users app and create them from scratch.

如果您的项目仍处于早期阶段并且您没有任何有价值的数据,则可以轻松地删除与用户应用程序甚至整个数据库相关的任何表,删除用户应用程序中的所有迁移并创建他们从头开始。

#1


2  

I think the issue is that you still have an old index on your username field that *es with the new type. The db_index=False argument has no effect because primary_key=True always generates an index.

我认为问题是你的用户名字段上仍然有一个与新类型冲突的旧索引。 db_index = False参数无效,因为primary_key = True始终生成索引。

You might be able to solve this by removing primary_key=True, creating a migration, and then re-adding it and creating another migration. Alternatively, you can do it by hand by dropping and re-creating the index. If you want to go down that path, consult this answer.

您可以通过删除primary_key = True,创建迁移,然后重新添加它并创建另一个迁移来解决此问题。或者,您可以通过删除和重新创建索引来手动完成。如果您想沿着这条路走下去,请参考这个答案。

If your project is still in an early stage and you don't have any valuable data, you can take the easy way out and drop any tables related to your users app or even the complete database, delete all migrations in the users app and create them from scratch.

如果您的项目仍处于早期阶段并且您没有任何有价值的数据,则可以轻松地删除与用户应用程序甚至整个数据库相关的任何表,删除用户应用程序中的所有迁移并创建他们从头开始。