django1.8更改了model后要怎样重建数据库

# 如果你说用的是pycharm编译器的话：

使用 ctrl+alt+r 进入 manage界面

然后输入 makemigrations [appname] 创建数据库引导文件

然后使用 migrate [appname] 来把model变化同步到数据库

# [appname] 指你当前model所在的app，如果不指定appname ;则编译全部app

# 如果不是pycharm编译器的话，请再追问

使用多个数据库

New in Django 12: Please, see the release notes

大多数其他文档都假设使用单一数据库，本文主要讨论如何在 Django 中使用多个数据库。 使用多个数据库，要增加一些步骤。

定义你的数据库

使用多数据库的第一步是通过 DATABASES 设置要使用的数据库服务。这个 设置用于映射数据库别名和特定的联结设置字典，这是 Django 定义数据库一贯的手法。 字典内部的设置参见 DATABASES 文档。

数据库可以使用任何别名，但是 default 有特殊意义。当没有选择其他数据库时， Django 总是使用别名为 default 的数据库。因此，如果你没有定义一个名为 default 的数据库时，你应当小心了，在使用数据库前要指定你想用的数据库。

以下是一个定义两个数据库的 settingspy 代码片断。定义了一个缺省的 PostgreSQL 数据库和一个名为 users 的 MySQL 数据库：

DATABASES = { 'default': { 'NAME': 'app_data', 'ENGINE': 'djangodbbackendspostgresql_psycopg2', 'USER': 'postgres_user', 'PASSWORD': 's3krit' }, 'users': { 'NAME': 'user_data', 'ENGINE': 'djangodbbackendsmysql', 'USER': 'mysql_user', 'PASSWORD': 'priv4te' } }

如果你尝试访问 DATABASES 设置中没有定义的数据库， Django 会抛出一个 djangodbutilsConnectionDoesNotExist异常。

同步你的数据库

syncdb 管理命令一次只 *** 作一个数据库。缺省情况下，它 *** 作 default 数据库。但是加上 --database 参数，你可以让 syncdb 同步不同的 数据库。所以要同步我们例子中的所有数据库的所有模型可以使用如下命令:

$ /managepy syncdb

$ /managepy syncdb --database=users

如果你不是同步所有的程序到同一个数据库中，你可定义一个 数据库路由 来为指定的模型实施特定的控制 策略。

如果你要精细地控制同步，那么还有一种方式是修改 sqlall 的输出，手工在 数据库中执行命令，命令如下:

$ /managepy sqlall sales | /managepy dbshell

使用其他管理命令

其他 *** 作数据库的 django-adminpy 命令与 syncdb 类似，他们一次只 *** 作一个数据库，使用 --database 来控制使用哪个数据库。

自动数据库路由

使用多数据库最简单的方法是设置一个数据库路由方案。缺省的路由方案确保对象 “紧贴”其原本的数据库（例如：一个对象从哪个数据库取得，就保存回哪个数据库）。 缺省的路由方案还确保如果一个数据库没有指定，所有的查询都会作用于 缺省 数据 库。

你不必为启动缺省路由方案作任何事，因为它是“开箱即用”的。但是，如果你要执行 一些更有趣的数据库分配行为的话，你可以定义并安装你自己的数据库路由。

数据库路由

一个数据库路由是一个类，这个类最多有四个方法：

db_for_read(model, hints)

建议 model 对象写 *** 作时使用的数据库。

如果一个数据库 *** 作可以提供对选择数据库有用的附加信息，那么可以通过 hints 字典提供。详见 下文 。

如果没有建议则返回 None 。

db_for_write(model, hints)

建议 model 对象读 *** 作时使用的数据库。

如果一个数据库 *** 作可以提供对选择数据库有用的附加信息，那么可以通过 hints 字典提供。详见 下文 。

如果没有建议则返回 None 。

allow_relation(obj1, obj2, hints)

当 obj1 和 obj2 之间允许有关系时返回 True ，不允许时返回 False ，或者没有 意见时返回 None 。这是一个纯粹的验证 *** 作，用于外键和多对多 *** 作中，两个对象 的关系是否被允许。

allow_syncdb(db, model)

决定 model 是否可以和 db 为别名的数据库同步。如果可以返回 True ， 如果不可以返回 False ，或者没有意见时返回 None 。这个方法用于决定一个给定 数据库的模型是否可用。

一个路由不必提供 所有 这些方法，可以省略其中一个或多个。如果其中一个方法被 省略了，那么 Django 会在执行相关检查时跳过相应路由。

提示参数

数据库路由接收的“提示”参数可用于决定哪个数据库应当接收一个给定的请求。

目前，唯一可以提供的提示参数是 实例 ，即一个与读写 *** 作相关的对象的实例。 可以是一个已保存的对象的实例，也可以是一个多对多关系中添加的实例。在某些情况下， 也可能没有对象的实例可以提供。路由会检查提示实例是否存在，并相应地决定是否改变 路由行为。

使用路由

数据库路由使用 DATABASE_ROUTERS 设置来安装。这个设置定义一个类名称 列表，每个类定义一个用于主路由 (djangodbrouter) 的路由。

主路由用于 Django 分配数据库 *** 作。当一个查询想要知道使用哪个数据库时，会提供 一个模型和一个提示（如果有的话），并调用主路由。

Django 就会按次序尝试每个路由，

直到找到合适的路由建议。如果找不到路由建议就会尝试实例提示的当前的 _statedb 。如果没有提供路由提示，或者实例没有当前数据库状态，那么

主路由会 分配 缺省 数据库。

一个例子

仅用于示例目的！

这个例子仅用于展示路由如何改变数据库的使用。本例有意忽略了一些复杂的东西以 便于更好的展示路由是如何工作的。

如果任何一个 myapp 中的模型包含与 另一个 数据库中模型的关系时，本例 是无效的。参见 跨数据库关系一节中介绍 的 Django 引用完整性问题。

本例的主/从配置也是有缺陷的：它没有处理复制延时（比如因为把写 *** 作传递给从 数据库耗费时间而产生的查询不一致），也没有考虑与数据库使用策略的交互作用。

那么，这个例子有什么用呢？本例仅用于演示一个 myapp 存在于 other 数据库， 所有其他模型之间是主/从关系，且存在于 master 、 slave1 和 slave2 数据库。本例使用了两个路由:

class MyAppRouter(object): """ 一个控制 myapp 应用中模型的 所有数据库 *** 作的路由 """ def db_for_read(self, model, hints): "myapp 应用中模型的 *** 作指向 'other'" if model_metaapp_label == 'myapp': return 'other' return None def db_for_write(self, model, hints): "myapp 应用中模型的 *** 作指向 'other'" if model_metaapp_label == 'myapp': return 'other' return None def allow_relation(self, obj1, obj2, hints): " 如果包含 myapp 应用中的模型则允许所有关系 " if obj1_metaapp_label == 'myapp' or obj2_metaapp_label == 'myapp': return True return None def allow_syncdb(self, db, model): " 确保 myapp 应用只存在于 'other' 数据库 " if db == 'other': return model_metaapp_label == 'myapp' elif model_metaapp_label == 'myapp': return False return None class MasterSlaveRouter(object): """ 一个设置简单主/从定义 的路由 """ def db_for_read(self, model, hints): " 所有读 *** 作指向一个随机的从数据库 " return randomchoice(['slave1','slave2']) def db_for_write(self, model, hints): " 所有写 *** 作指向主数据库 " return 'master' def allow_relation(self, obj1, obj2, hints): " 允许数据库池中的两个对象间的任何关系 " db_list = ('master','slave1','slave2') if obj1_statedb in db_list and obj2_statedb in db_list: return True return None def allow_syncdb(self, db, model): " 显示地放置所有数据库中的模型 " return True

然后在你的设置文件增加如下内容（把 pathto 替换为你定义路由的模型的路径 ）:

DATABASE_ROUTERS = ['pathtoMyAppRouter', 'pathtoMasterSlaveRouter']

这个设置中，路由的顺序是很重要的，因为查询时是按这个设置中的顺序依次查询的。上 例中， MyAppRouter 先于MasterSlaveRouter ，因此， myapp 中的模型就 优先于其他模型。如果 DATABASE_ROUTERS 设置中两个路由的顺序变换了， 那么 MasterSlaveRouterallow_syncdb() 会优先执行。因为 MasterSlaveRouter 是 包罗万象的，这样就会导致所有模型可以使用所有数据库。

设置好之后让我们来运行一些代码:

>>> # 从 'credentials' 数据库获得数据 >>> fred = Userobjectsget(username='fred') >>> fredfirst_name = 'Frederick' >>> # 保存到 'credentials' 数据库 >>> fredsave() >>> # 随机从从数据库获得数据 >>> dna = Personobjectsget(name='Douglas Adams') >>> # 新对象创建时还没有分配数据库 >>> mh = Book(title='Mostly Harmless') >>> # 这个赋值会向路由发出请求，并把 mh 的数据库设置为与 author 对象同样的 >>> # 数据库 >>> mhauthor = dna >>> # 这会强制 'mh' 实例使用主数据库 >>> mhsave() >>> # 但如果我们重新获取对象，就会从从数据库中获取 >>> mh = Bookobjectsget(title='Mostly Harmless')

手动选择数据库

Django 也提供一个可以让你通过代码完全控制数据库使用的 API 。手动定义数据库分配 优先于路由。

为一个 查询集 手动选择一个数据库

你可以在 查询集 “链”中的任何点为 查询集 选择数据库。我们通过在 查询集 上调用 using() 来得到使用指定数据库的另一个 查询集 。

using() 使用一个参数：你想要运行查询的数据库的别名。例如:

>>> # 这会运行在“缺省”数据库上。 >>> Authorobjectsall() >>> # 这同样会运行在“缺省”数据库上。 >>> Authorobjectsusing('default')all() >>> # 这会运行在“ other ”数据库上。 >>> Authorobjectsusing('other')all()

为 save() 选择一个数据库

在使用 Modelsave() 时加上 using 关键字可以指定保存到哪个数据库。

例如，要把一个对象保存到 legacy_users 数据库应该这样做:

>>> my_objectsave(using='legacy_users')

如果你不定义 using ，那么 save() 方法会根据路由分配把数据保存到缺省 数据库中。

把一个对象从一个数据库移动到另一个数据库

当你已经在一个数据库中保存了一个对象后，你可能会使用 save(using=) 把这个 对象移动到另一个数据库中。但是，如果你没有使用恰当的方法，那么可能会出现意想不 到的后果。

假设有如下的例子:

>>> p = Person(name='Fred') >>> psave(using='first') # （第一句） >>> psave(using='second') # （第二名）

在第一名中，一个新的 Person 对象被保存到 first 数据库中。这时， p 还没有一个主键，因此 Django 执行了一个INSERT SQL 语句。这样就会创建一个 主键，并将这个主键分配给 p 。

在第二句中，因为 p 已经有了一个主键，所以 Django 在保存对象时会尝试在新的 数据库中使用这个主键。如果 second数据库中没有使用这个主键，那就不会有问题， 该对象会复制到新数据库。

然而，如果 p 的主键在 second 数据库中已经使用过了，那么 second 使用 这个主键的已存在的对象将会被 p 覆盖。

有两种方法可以避免上述情况的发生。第一，你可以清除实例的主键。如果一个对象没有 主主键，那么 Django 会把它看作一个新对象，在保存到 second 数据库中时就不会 带来数据的损失:

>>> p = Person(name='Fred') >>> psave(using='first') >>> ppk = None # 清除主键。 >>> psave(using='second') # 写入一个全新的对象。

第二种方法是在 save() 方法中使用 force_insert 选项来保证 Django 执行 一个 INSERT SQL:

>>> p = Person(name='Fred') >>> psave(using='first') >>> psave(using='second', force_insert=True)

这样可以保证名为 Fred 的人员在两个数据库中使用相同的主键。如果在保存到 second 数据库时主键已被占用，会抛出一个错误。

选择一个要删除数据的数据库

缺省情况下，一个现存对象从哪个数据库得到，删除这个对象也会在这个数据库中进行:

>>> u = Userobjectsusing('legacy_users')get(username='fred') >>> udelete() # 会从 `legacy_users` 数据库中删除

通过向 Modeldelete() 方法传递 using 关键字参数可以定义在哪个数据库中删除 数据。 using 的用法与 save() 方法中使用这个参数类似。

例如，假设我们要把一个用户从 legacy_users 数据库移动到 new_users 数据库 可以使用如下命令:

>>> user_objsave(using='new_users') >>> user_objdelete(using='legacy_users')

多数据库情况下使用管理器

在管理器上使用 db_manager() ，可以让管理器访问一个非缺省数据库。

例如，假设你有一个 *** 作数据库的自定义管理器 Userobjectscreate_user() 。

因为 create_user() 是一个管理器方法，不是一个 查询集 ，所以你不能

用 Userobjectsusing('new_users')create_user() 。（ create_user() 方法

只能用于 Userobjects 管理器，而不能用于，管理器衍生出的 查询集 。） 解决方法是使用 db_manager() ，就象下面这样:

Userobjectsdb_manager('new_users')create_user()

db_manager() 返回的是绑定到你指定的数据库的管理器的一个副本。

多数据库情况下使用 get_query_set()

如果你在管理器中重载了 get_query_set() ，请确保在其父类中也调用了相同的方法 （使用 super() ）或者正确处理管理器中的 _db 属性（一个包含要使用的数据库 名称的字符串）。

例如，如果你要从 get_query_set 方法返回一个自定义 查询集 类，那么你可以 这样做:

class MyManager(modelsManager): def get_query_set(self): qs = CustomQuerySet(selfmodel) if self_db is not None: qs = qsusing(self_db) return qs

在 Django 管理接口中使用多数据库

Django 的管理接口没有明显支持多数据库。如果想要支持的话你必须写自定义 ModelAdmin 。

如果要支持多数据库，那么 ModelAdmin 对象有五个方法要自定义:

class MultiDBModelAdmin(adminModelAdmin): # 为方便起见定义一个数据库名称常量。 using = 'other' def save_model(self, request, obj, form, change): # 让 Django 保存对象到 'other' 数据库。 objsave(using=selfusing) def delete_model(self, request, obj): # 让 Django 从 'other' 数据库中删除对象。 objdelete(using=selfusing) def queryset(self, request): # 让 Django 在 'other' 数据库中搜索对象。 return super(MultiDBModelAdmin, self)queryset(request)using(selfusing) def formfield_for_foreignkey(self, db_field, request=None, kwargs): # 让 Django 基于 'other' 数据库生成外键控件。 return super(MultiDBModelAdmin, self)formfield_for_foreignkey(db_field, request=request, using=selfusing, kwargs) def formfield_for_manytomany(self, db_field, request=None, kwargs): # 让 Django 基于 'other' 数据库生成多对多关系控件。 return super(MultiDBModelAdmin, self)formfield_for_manytomany(db_field, request=request, using=selfusing, kwargs)

Model是django项目的基础, 如果一开始没有好好设计好, 那么在接下来的开发过程中就会遇到更多的问题 然而,

大多数的开发人员都容易在缺少思考 的情况下随意的增加或修改model 这样做的后果就是, 在接下来的开发过程中,

我们不得不做出更多努力来修正这些错误

因此, 在修改model时, 一定尽可能的经过充分的考虑再行动! 以下列出的是我们经常用到的一些工具和技巧:

South, 用于数据迁移, 我们会在每个django项目中都用到 但到django 17时, 将会有djangodbmigrations代替

django-model-utils, 用于处理常见的模式, 例如TimeStampedModel

django-extensions, 主要用到shell_plus命令, 该命令会在shell中自动载入所有的app的model

1 基本原则

第一, 将model分布于不同的app中 如果你的django项目中, 有一个app拥有超过20个model, 那么, 你就应当考虑分拆该app了 我们推荐每个app拥 有不超过5个model

第二, 尽量使用ORM 我们需要的大多数数据库索引都能通过Object-Relational-Model实现,

且ORM带给我们许多快捷方式, 例如生成SQL语句, 读取/更新数据库时的安全验证 因此, 如果能使用简单的ORM语句完成的,

应当尽量使用ORM 只有当纯SQL语句极大地简化了ORM语句时, 才使用纯SQL语句 并且, 在写纯SQL语句是,

应当优先考虑使用raw(), 再是extra()

第三, 必要时添加index 添加db_index=True到model中非常简单, 但难的是理解何时应该添加 在建立model时, 我们事先不会添加index, 只有当 以下情况时, 才会考虑添加index:

在所有的数据库查询中使用率在10%-25%时

或当有真实的数据, 或能正确估计出使用index后的效果确实满意时

第四, 注意model的继承 model的继承在django中需要十分小心, django提供了三种继承方式, 1abstract

base class继承(不要和Pyhton标准库的abc模块 搞混), 2多表(multi-table)继承, 3proxy

model继承 下表罗列了这三种继承的优劣:

model继承类型

优势

劣势

不使用继承, 即每个相同的field会重复出现在不同的model中

容易明白model和数据表的关系

如果有大量相同的field, 会较难维护

abstract base class继承, 即只有继承自该类的model才会有数据表, 其自身没有对应的数据表

不用在每个model重复编写相同的field 也没有多表继承带来的过多消耗

无法单独使用其共同的abstract base class

多表(multi-table)继承

每个model都有数据表, 因此可以既使用母表, 又使用子表 也能通过parentchild从母表访问子表

增加了消耗, 因为每次查询子表, 都会自动查询其母表 强烈建议不使用这一方法!

proxy model继承, 即只有原始model才会有相应的数据表

在不建立新数据表的情况下, 使我们拥有不同行为的model

无法修改model的field

django的创造者和其他许多开发人员都认为, 多表继承的方法不是一个良好的方法 因此我们强烈建议大家不要使用该方法 下面列举了一些常见的如何 选择model继承的情形:

如果只有少数model拥有重复的field时, 大可不必使用model继承, 只需要在每个model中添加这些相同的field即可

如果有足够的model拥有重复的field时, 大多是情况下, 可以使用abstract base class继承, 将相同的field提取到abstract base class 中

Proxy model继承很少被用到, 和其他两种继承也有着许多不一样之处

请不要使用多表(multi-table)继承, 因为它既消耗资源又复杂, 如果可以, 尽量使用OneToOneFields和ForeignKeys代替

django项目中, 创建时间和修改时间这两个field是最用到的, 下面给出一个abstract base class继承的例子:

# modelspy

from djangodb import models

class TimeStampedModel(modelsModel):

"""

abstract base class, 提供创建时间和修改时间两个通用的field

"""

created = modelsDateTimeField(auto_now_add=True)

modified = modelsDateTimeField(auto_now=True)

class Meta:

abstract = True

注意以上代码的最后两行, 正式这两行将这一model变味了abstract base class, 下面以TimeStampedModel为abstract base class建立model:

from djangodb import models

class Article(TimeStampedModel):

title = modelsCharField(max_length=200)

以上两个class, 在执行syncdb时, 只会建立一个数据表, 这也正是我们希望得到的

第五, 使用south进行数据迁移, 可以参见以前的文章: 如何在 Django 中使用 django-south, 实现数据迁移 (data migrations)

2 Django Model的设计

如何设计出好的django model可能是最难也是最复杂的一个话题了, 在此, 我们看看一些基本的技巧吧:

a 规范化

我们首先建议了解数据库规范化(database normalization) 如果你还不清楚这是什么, 那么,

我们强烈建议你先阅读一下相关的书籍, 或搜索"关系 型数据库设计"或"数据库规范化" 在创建django model之前,

应当首先保证设计的数据库是规范化的

b cache

正确的使用cache能帮助我们提高数据库的性能 详细的信息, 我们会在今后的文章中作进一步介绍

c 何时使用null和blank

当定义model field时, 我们可以设置null=True和blank=True (默认都是False), 知道何时设置null和blank对于开发人员也是十分重要的, 在下 面的表格中, 我们一一列举了如何使用这两个选项:

Field 类型

设置null=True

设置blank=True

CharField,

TextField,

SlugField,

EmailField,

CommaSeparatedIntegerField等

不要设置

django规定储存空字符串来代表空值, 当从数据库中读取NULL或空值时都为空字符串

可以设置

设置后允许接受widget中为空值(即不填写), 储存到数据库时空值变为空字符串

FileField,

ImageField

不要设置

django实际储存的是路径的字符串, 因此同上

可以设置

同上

BooleanField

不要设置

因为有NullBooleanField代替

不要设置

IntegerField,

FloatField,

DecimalField等

可以设置

如果你希望在数据库中能储存NULL

可以设置

设置后允许接受widget中为空值(即不填写), 设置为True时必须同时设置null=True

DateTimeField,

DateField,

TimeField等

可以设置

如果你希望在数据库中能储存NULL

可以设置

设置后允许接受widget中为空值(即不填写), 设置为True时必须同时设置null=True

ForeignKey,

ManyToManyField,

OneToOneField

可以设置

如果你希望在数据库中能储存NULL

可以设置

设置后允许接受widget中为空值(即不填写)

GenericIPAddressField

可以设置

如果你希望在数据库中能储存NULL

可以设置

设置后允许接受widget中为空值(即不填写)

IPAddressField

不推荐设置

用GenericIPAddressField代替

不推荐设置

用GenericIPAddressField代替

d 什么时候使用BinaryField

在django 16中, 新增了BinaryField, 用于储存二进制数据(binary data或 bytes)

对于BinaryField, 我们无法使用ORM的filters, excludes或其他SQL *** 作 但在少数情况下,

我们会用到BinaryField, 例如MessagePack格式的内容, 传感器接受的原始数据和压缩数据等 但需要注意 的是, Binary

Data一般都十分庞大, 因此可能会拖慢数据库的速度 如果发生这一现象, 我们可以将binary data储存在文件中,

然后使用FileField储 存该文件的路径信息

还有, 不要从BinaryField中直接读取文件并呈献给用户 因为, 1 从数据库读写总是比从文件系统读写慢; 2 数据库备份会变得十分庞大, 花费更多 的时间; 3 获得文件的过程, 增加了从django到数据库的这一环节

3 不要替换默认的Model Manager

从ORM获取model, 实际上是通过django中的Model manager完成的, django为每一个model提供了默认的model manager, 我们不建议将其替换掉, 因为:

当使用model继承时, model会继承 abstract base class model的model manager, 而不会继承非abstract base class的manager

model的第一个model manager通常作为默认的manager, 当被替换时, 可能会发生不可预测的问题

4 数据库事务 (Transaction)

在django 16中, ORM默认会autocommit每一个数据库查询, 也就是说,

每次使用mcreate()或mupdate()时, 在数据库中马上就会做出相应的修 改 这样做的好处就是简化了初学者对ORM的理解

但坏处就是, 当一个view中包含两个数据库修改, 可能一个成功, 但另一个失败, 这就可能导致数据库不 完整, 给我们带来很大的危险

解决这一问题的方法就是使用数据库transaction, 即将一系列数据库 *** 作包含在一个transaction中,

当其中有一个失败时, 其他 *** 作也会自动回退 Django 16 为我们带来了一套崭新的既简单又强大的transaction机制,

使我们方便的使用数据库transaction

a 将整个>

一般写在模型中，也就是models

如果你要使用django自带的orm，那么需要去读一读django模型方面的资料

这里举个简单的例子：

class User(modelsModel):

    username = modelsCharField(verbose_name='用户名',max_length=20)

    password = modelsCharField(verbose_name='密码',max_length=20)

    def __unicode__(self):

        return selfusername

这里定义的User类，在建模完成后，在数据库中对应就是app_User表，如果需要查询，那么

Userobjectsfilter(all) #所有行

更新：

p = Userobjectsget('username='name'')

p = 'name1'

psave()

删除：

Userobjectsget('username='name'')delete()

如果不用自带的ORM，那么用mysqldb模块来处理，这个没有什么可说的，使用标准sql语句即可

错误代码 1045

Access denied for user 'root'@'localhost'

(using password:YES)

如果你的mysql也出现以上这种提示,

建议你逐个字看完我这篇文章再按以下方法来尝试解决问题

这是mysql数据库很多时候出现的问题, 网上流传很多解决办法 有人按照那些方法, 还真可以把问题解决了; 但也有很多人按那些方法解决不了问题!

网上的那些方法, 很多都没有明确指出是什么版本的mysql, 所以导致问题者不能对症下药

出现这个问题, 通过停止/重启 mysql 服务, 是可以解决的, 这个是最简单的办法! 对于不懂得什么叫做"停止/重启mysql服务"的人来说,

这个最简单的办法就是把服务器主机进行重新启动(就是把你的电脑进行重新启动)

以上是方法A! (这个方法适合任何版本的mysql)

以下是方法B:(方法仅适用于MySQL4026 版本!!! (我估计,

40的其他版本应该也可以的))

网上也有说, 就是对root进行重改密码 对于网上流传的改密码方法, 也是可行的 请参考以下:

DOS下修改ROOT密码：当然后面安装PHPMYADMIN后修改密码也可以通过PHPMYADMIN修改

格式：mysqladmin -u用户名 -p旧密码 password

新密码

例：给root加个密码ideacmblog

首先在进入CMD命令行，转到MYSQL目录下的bin目录，然后键入以下命令

mysqladmin

-uroot password ideacmblog

注：因为开始时root没有密码，所以-p旧密码一项就可以省略了。

D:\php\MySQL\bin>mysqladmin -uroot password

ideacmblog回车后ROOT密码就设置为ideacmblog了

但是, 请注意了, 以上方法仅适用于MySQL4026

版本!!! (我估计, 40的其他版本应该也可以的)

方法C:

好了, 扯了那么多, 以上的两个方法都不是我本人测试过的, 本人不对真实性负责!

而现在我说一下本人亲自试过的方法, 以供参考:

话说今天, 我的服务器所有php及使用了mysql数据库的网站, 均挂掉了! 无法打开,

并有以下提示:

错误代码 1045

Access denied for

user 'root'@'localhost' (using password:YES)

一开始我也是不断搜索google(我本人不喜欢百度!),

去找寻解决的办法 看了很多, 也参照执行了, 事实上也是解决不了问题 后来我想到了是版本的问题, 不同的mysql版本,

解决办法是不一定一样的!!记住

我的mysql版本是: 5022

(mysql-essential-5022-win32)

今天一整天, 那些php网站均罢工 到今晚才有时间上去服务器继续寻找方法, 但仍然解决不了

最后, 我决定把mysql卸掉重新安装!

卸载很快, 而且不需要重新启动计算机

于是, 继续进行安装

第一步:

打开这个mysql-essential-5022-win32exe文件;

第二步: 见到窗口d出, 并点击 Next>

进入下一步;

第三步: 选择 Custom 项, 并点击

Next> 进入下一步;

第四步: 到这一步要注意了, 点击

Change 选择你原安装mysql的目录; 选择后, 继续点击Next> 进入下一步;

第五步: 点击 Install

进行安装

安装至下一步, 会提示你进行注册, 选择最后一项, 即跳过注册,

进入下一步正式完成安装

安装完成后, 继续d出一个窗口, 提示你是不是立刻进行配置,

选择 Next

选择Standard Configuration继续点击

Next 进入下一步

这一步里, 把上面那行的勾去掉, 只在 Include

PATH 那行打勾, 继续点击 Next 进入下一步

在这一步, 点击中间的"Ex"那顶,

接着配置完毕!

在使用一些流行的Web框架（如Django、Ruby on Rails等）进行应用程序开发时，通常会使用一个工具来记录和管理数据库变更的文件，这个工具通常被称为“迁移(Migration)”。

在Django中，迁移是通过创建一个Python文件来实现的，其中包含一些数据库变更的指令，例如创建或删除表格，添加或删除字段等。当应用程序启动或执行migrate命令时，Django将根据这些迁移文件中的指令来同步数据库模式，确保数据库与应用程序代码的最新版本保持一致。

在Ruby on Rails中，类似的工具被称为“迁移(Migration)”或“数据库迁移(Database Migration)”，可以使用命令行工具生成迁移文件并执行迁移 *** 作。

总之，无论是哪个Web框架，迁移文件都旨在帮助开发人员轻松管理和维护应用程序和数据库之间的关系，避免了手动执行数据库变更 *** 作所带来的复杂性和错误。

view中的处理函数，如果请求方式为默认，则从数据库中读取数据，通过上下文传递到模板绑定，如果是POST，则接收更新处理：

def handle_data(request,rid):

if formmethod=="POST":

#检索表单值，更新数据

else:

r = Resumeobjectsget(pk=rid)

return render(request,'testhtml',{"resume":r})

模板页

<input value="{{resumetitle}}" />

以上就是关于django1.8更改了model后要怎样重建数据库全部的内容，包括:django1.8更改了model后要怎样重建数据库、如何在django中使用多个数据库、如何正确的使用和设置Database和Model等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！