Xem ngay Hướng dẫn này có một khóa học video liên quan được tạo bởi nhóm Real Python. Xem nó cùng với hướng dẫn bằng văn bản để hiểu sâu hơn của bạn: Django Migrations 101
Kể từ phiên bản 1.7, Django đã hỗ trợ sẵn cho việc di chuyển cơ sở dữ liệu. Trong Django, di chuyển cơ sở dữ liệu thường đi đôi với các mô hình:bất cứ khi nào bạn viết mã một mô hình mới, bạn cũng tạo ra một di chuyển để tạo bảng cần thiết trong cơ sở dữ liệu. Tuy nhiên, việc di chuyển có thể làm được nhiều hơn thế.
Bạn sẽ tìm hiểu cách hoạt động của Django Migrations và cách bạn có thể tận dụng tối đa chúng qua bốn bài báo và một video:
- Phần 1:Django Migrations:A Primer (bài viết hiện tại)
- Phần 2:Tìm hiểu sâu hơn về các cuộc di cư
- Phần 3:Di chuyển dữ liệu
- Video:Django 1.7 Migrations - mồi
Trong bài viết này, bạn sẽ thấy thoải mái với việc di chuyển Django và tìm hiểu những điều sau:
- Cách tạo các bảng cơ sở dữ liệu mà không cần viết bất kỳ SQL nào
- Cách tự động sửa đổi cơ sở dữ liệu của bạn sau khi bạn thay đổi mô hình của mình
- Cách hoàn nguyên các thay đổi đã thực hiện đối với cơ sở dữ liệu của bạn
Tiền thưởng miễn phí: Nhấp vào đây để có quyền truy cập vào Hướng dẫn tài nguyên học tập Django (PDF) miễn phí, chỉ cho bạn các mẹo và thủ thuật cũng như các cạm bẫy phổ biến cần tránh khi xây dựng ứng dụng web Python + Django.
Các vấn đề mà di cư giải quyết
Nếu bạn chưa quen với Django hoặc phát triển web nói chung, bạn có thể không quen với khái niệm di chuyển cơ sở dữ liệu và có vẻ không rõ ràng tại sao chúng là một ý tưởng hay.
Trước tiên, hãy nhanh chóng xác định một vài thuật ngữ để đảm bảo mọi người đều ở trên cùng một trang. Django được thiết kế để hoạt động với cơ sở dữ liệu tương đối, được lưu trữ trong hệ thống quản lý cơ sở dữ liệu quan hệ như PostgreSQL, MySQL hoặc SQLite.
Trong cơ sở dữ liệu quan hệ, dữ liệu được tổ chức trong các bảng. Một bảng cơ sở dữ liệu có một số cột nhất định, nhưng nó có thể có bất kỳ số hàng nào. Mỗi cột có một kiểu dữ liệu cụ thể, như một chuỗi có độ dài tối đa nhất định hoặc một số nguyên dương. Mô tả của tất cả các bảng với các cột và kiểu dữ liệu tương ứng của chúng được gọi là lược đồ cơ sở dữ liệu.
Tất cả các hệ thống cơ sở dữ liệu được Django hỗ trợ đều sử dụng ngôn ngữ SQL để tạo, đọc, cập nhật và xóa dữ liệu trong cơ sở dữ liệu quan hệ. SQL cũng được sử dụng để tạo, thay đổi và xóa chính các bảng cơ sở dữ liệu.
Làm việc trực tiếp với SQL có thể khá cồng kềnh, vì vậy, để giúp cuộc sống của bạn dễ dàng hơn, Django đi kèm với trình ánh xạ quan hệ đối tượng, viết tắt là ORM. ORM ánh xạ cơ sở dữ liệu quan hệ với thế giới của lập trình hướng đối tượng. Thay vì xác định bảng cơ sở dữ liệu trong SQL, bạn viết mô hình Django bằng Python. Mô hình của bạn xác định các trường cơ sở dữ liệu, tương ứng với các cột trong bảng cơ sở dữ liệu của chúng.
Dưới đây là một ví dụ về cách một lớp mô hình Django được ánh xạ tới một bảng cơ sở dữ liệu:
Nhưng việc chỉ định nghĩa một lớp mô hình trong một tệp Python không làm cho một bảng cơ sở dữ liệu xuất hiện một cách kỳ diệu. Tạo các bảng cơ sở dữ liệu để lưu trữ các mô hình Django của bạn là công việc của quá trình di chuyển cơ sở dữ liệu. Ngoài ra, bất cứ khi nào bạn thực hiện thay đổi đối với mô hình của mình, chẳng hạn như thêm trường, cơ sở dữ liệu cũng phải được thay đổi. Việc di chuyển cũng xử lý điều đó.
Dưới đây là một số cách di cư Django giúp cuộc sống của bạn dễ dàng hơn.
Thực hiện thay đổi cơ sở dữ liệu mà không cần SQL
Nếu không có di chuyển, bạn sẽ phải kết nối với cơ sở dữ liệu của mình và nhập một loạt lệnh SQL hoặc sử dụng công cụ đồ họa như PHPMyAdmin để sửa đổi lược đồ cơ sở dữ liệu mỗi khi bạn muốn thay đổi định nghĩa mô hình của mình.
Trong Django, chuyển đổi chủ yếu được viết bằng Python, vì vậy bạn không cần phải biết bất kỳ SQL nào trừ khi bạn có các trường hợp sử dụng thực sự nâng cao.
Tránh lặp lại
Việc tạo một mô hình và sau đó viết SQL để tạo các bảng cơ sở dữ liệu cho nó sẽ lặp đi lặp lại.
Quá trình di chuyển được tạo từ các mô hình của bạn, đảm bảo bạn không lặp lại chính mình.
Đảm bảo Định nghĩa Mô hình và Lược đồ Cơ sở dữ liệu trong Đồng bộ
Thông thường, bạn có nhiều trường hợp cơ sở dữ liệu của mình, ví dụ:một cơ sở dữ liệu cho mỗi nhà phát triển trong nhóm của bạn, một cơ sở dữ liệu để thử nghiệm và một cơ sở dữ liệu với dữ liệu trực tiếp.
Nếu không có di chuyển, bạn sẽ phải thực hiện bất kỳ thay đổi lược đồ nào trên từng cơ sở dữ liệu của mình và bạn sẽ phải theo dõi những thay đổi nào đã được thực hiện đối với cơ sở dữ liệu nào.
Với Django Migrations, bạn có thể dễ dàng giữ nhiều cơ sở dữ liệu đồng bộ với các mô hình của mình.
Theo dõi thay đổi lược đồ cơ sở dữ liệu trong kiểm soát phiên bản
Một hệ thống kiểm soát phiên bản, như Git là tuyệt vời cho mã, nhưng không quá tốt cho các lược đồ cơ sở dữ liệu.
Vì quá trình di chuyển là Python thuần túy trong Django, bạn có thể đặt chúng vào hệ thống kiểm soát phiên bản giống như bất kỳ đoạn mã nào khác.
Đến giờ, bạn hy vọng tin rằng di chuyển là một công cụ hữu ích và mạnh mẽ. Hãy bắt đầu học cách giải phóng sức mạnh đó.
Thiết lập dự án Django
Trong suốt hướng dẫn này, bạn sẽ làm việc trên một ứng dụng theo dõi Bitcoin đơn giản như một dự án ví dụ.
Bước đầu tiên là cài đặt Django. Đây là cách bạn thực hiện điều đó trên Linux hoặc macOS X bằng môi trường ảo:
$ python3 -m venv env
$ source env/bin/activate
(env) $ pip install "Django==2.1.*"
...
Successfully installed Django-2.1.3
Bây giờ bạn đã tạo một môi trường ảo mới và kích hoạt nó, cũng như cài đặt Django trong môi trường ảo đó.
Lưu ý rằng trên Windows, bạn sẽ chạy env/bin/activate.bat thay vì source env/bin/activate để kích hoạt môi trường ảo của bạn.
Để dễ đọc hơn, các ví dụ về bảng điều khiển sẽ không bao gồm (env) một phần của lời nhắc kể từ bây giờ.
Với Django được cài đặt, bạn có thể tạo dự án bằng các lệnh sau:
$ django-admin.py startproject bitcoin_tracker
$ cd bitcoin_tracker
$ python manage.py startapp historical_data
Điều này cung cấp cho bạn một dự án đơn giản và một ứng dụng có tên là historical_data . Bây giờ bạn sẽ có cấu trúc thư mục này:
bitcoin_tracker/
|
├── bitcoin_tracker/
│ ├── __init__.py
│ ├── settings.py
│ ├── urls.py
│ └── wsgi.py
|
├── historical_data/
│ ├── __init__.py
│ ├── admin.py
│ ├── apps.py
│ ├── migrations/
│ │ └── __init__.py
| |
│ ├── models.py
│ ├── tests.py
│ └── views.py
|
└── manage.py
Trong bitcoin_tracker thư mục, có hai thư mục con:bitcoin_tracker cho các tệp toàn dự án và historical_data chứa các tệp cho ứng dụng bạn đã tạo.
Bây giờ, để tạo một mô hình, hãy thêm lớp này vào historical_data/models.py :
class PriceHistory(models.Model):
date = models.DateTimeField(auto_now_add=True)
price = models.DecimalField(max_digits=7, decimal_places=2)
volume = models.PositiveIntegerField()
Đây là mô hình cơ bản để theo dõi giá Bitcoin.
Ngoài ra, đừng quên thêm ứng dụng mới tạo vào settings.INSTALLED_APPS . Mở bitcoin_tracker/settings.py và nối thêm historical_data vào danh sách INSTALLED_APPS , như thế này:
INSTALLED_APPS = [
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'historical_data',
]
Các cài đặt khác là tốt cho dự án này. Hướng dẫn này giả định rằng dự án của bạn được định cấu hình để sử dụng cơ sở dữ liệu SQLite, là cơ sở dữ liệu mặc định.
Tạo di chuyển
Với mô hình đã tạo, điều đầu tiên bạn cần làm là tạo một chuyển đổi cho nó. Bạn có thể thực hiện việc này bằng lệnh sau:
$ python manage.py makemigrations historical_data
Migrations for 'historical_data':
historical_data/migrations/0001_initial.py
- Create model PriceHistory
Lưu ý: Chỉ định tên của ứng dụng, historical_data , Là tùy chọn. Việc tắt nó sẽ tạo ra sự di chuyển cho tất cả các ứng dụng.
Thao tác này tạo tệp di chuyển hướng dẫn Django cách tạo bảng cơ sở dữ liệu cho các mô hình được xác định trong ứng dụng của bạn. Hãy cùng nhìn lại cây thư mục:
bitcoin_tracker/
|
├── bitcoin_tracker/
│ ├── __init__.py
│ ├── settings.py
│ ├── urls.py
│ └── wsgi.py
|
├── historical_data/
│ ├── migrations/
│ │ ├── 0001_initial.py
│ │ └── __init__.py
| |
│ ├── __init__.py
│ ├── admin.py
│ ├── apps.py
│ ├── models.py
│ ├── tests.py
│ └── views.py
|
├── db.sqlite3
└── manage.py
Như bạn có thể thấy, migrations bây giờ thư mục chứa một tệp mới:0001_initial.py .
Lưu ý: Bạn có thể nhận thấy rằng việc chạy makemigrations lệnh cũng đã tạo tệp db.sqlite3 , chứa cơ sở dữ liệu SQLite của bạn.
Khi bạn cố gắng truy cập vào một tệp cơ sở dữ liệu SQLite3 không tồn tại, nó sẽ tự động được tạo.
Hành vi này là duy nhất đối với SQLite3. Nếu bạn sử dụng bất kỳ chương trình phụ trợ cơ sở dữ liệu nào khác như PostgreSQL hoặc MySQL, bạn phải tự tạo cơ sở dữ liệu trước đang chạy makemigrations .
Bạn có thể xem qua cơ sở dữ liệu bằng dbshell lệnh quản lý. Trong SQLite, lệnh liệt kê tất cả các bảng chỉ đơn giản là .tables :
$ python manage.py dbshell
SQLite version 3.19.3 2017-06-27 16:48:08
Enter ".help" for usage hints.
sqlite> .tables
sqlite>
Cơ sở dữ liệu vẫn trống. Điều đó sẽ thay đổi khi bạn áp dụng quá trình di chuyển. Nhập .quit để thoát khỏi trình bao SQLite.
Áp dụng Di chuyển
Bây giờ bạn đã tạo quá trình di chuyển, nhưng để thực sự thực hiện bất kỳ thay đổi nào trong cơ sở dữ liệu, bạn phải áp dụng nó bằng lệnh quản lý migrate :
$ python manage.py migrate
Operations to perform:
Apply all migrations: admin, auth, contenttypes, historical_data, sessions
Running migrations:
Applying contenttypes.0001_initial... OK
Applying auth.0001_initial... OK
Applying admin.0001_initial... OK
Applying admin.0002_logentry_remove_auto_add... OK
Applying admin.0003_logentry_add_action_flag_choices... OK
Applying contenttypes.0002_remove_content_type_name... OK
Applying auth.0002_alter_permission_name_max_length... OK
Applying auth.0003_alter_user_email_max_length... OK
Applying auth.0004_alter_user_username_opts... OK
Applying auth.0005_alter_user_last_login_null... OK
Applying auth.0006_require_contenttypes_0002... OK
Applying auth.0007_alter_validators_add_error_messages... OK
Applying auth.0008_alter_user_username_max_length... OK
Applying auth.0009_alter_user_last_name_max_length... OK
Applying historical_data.0001_initial... OK
Applying sessions.0001_initial... OK
Có rất nhiều điều đang diễn ra ở đây! Theo kết quả đầu ra, quá trình di chuyển của bạn đã được áp dụng thành công. Nhưng tất cả những cuộc di cư khác đến từ đâu?
Nhớ cài đặt INSTALLED_APPS ? Một số ứng dụng khác được liệt kê ở đó cũng có tính năng di chuyển và migrations lệnh quản lý áp dụng di chuyển cho tất cả các ứng dụng đã cài đặt theo mặc định.
Có một cái nhìn khác về cơ sở dữ liệu:
$ python manage.py dbshell
SQLite version 3.19.3 2017-06-27 16:48:08
Enter ".help" for usage hints.
sqlite> .tables
auth_group django_admin_log
auth_group_permissions django_content_type
auth_permission django_migrations
auth_user django_session
auth_user_groups historical_data_pricehistory
auth_user_user_permissions
sqlite>
Bây giờ có nhiều bảng. Tên của họ cung cấp cho bạn một ý tưởng về mục đích của họ. Quá trình di chuyển mà bạn đã tạo ở bước trước đã tạo ra historical_data_pricehistory bàn. Hãy kiểm tra nó bằng cách sử dụng .schema lệnh:
sqlite> .schema --indent historical_data_pricehistory
CREATE TABLE IF NOT EXISTS "historical_data_pricehistory"(
"id" integer NOT NULL PRIMARY KEY AUTOINCREMENT,
"date" datetime NOT NULL,
"price" decimal NOT NULL,
"volume" integer unsigned NOT NULL
);
.schema lệnh in ra CREATE câu lệnh mà bạn sẽ thực thi để tạo bảng. Tham số --indent định dạng nó độc đáo. Ngay cả khi bạn không quen thuộc với cú pháp SQL, bạn có thể thấy rằng lược đồ của historical_data_pricehistory bảng phản ánh các trường của PriceHistory mô hình.
Có một cột cho mỗi trường và một cột bổ sung id cho khóa chính, mà Django tạo tự động trừ khi bạn chỉ định rõ ràng khóa chính trong mô hình của mình.
Đây là những gì sẽ xảy ra nếu bạn chạy migrations lệnh một lần nữa:
$ python manage.py migrate
Operations to perform:
Apply all migrations: admin, auth, contenttypes, historical_data, sessions
Running migrations:
No migrations to apply.
Không! Django ghi nhớ những di chuyển nào đã được áp dụng và không cố gắng chạy lại chúng.
Cần lưu ý rằng bạn cũng có thể giới hạn migrations lệnh quản lý cho một ứng dụng duy nhất:
$ python manage.py migrate historical_data
Operations to perform:
Apply all migrations: historical_data
Running migrations:
No migrations to apply.
Như bạn có thể thấy, Django hiện chỉ áp dụng di chuyển cho historical_data ứng dụng.
Khi bạn đang chạy quá trình di chuyển lần đầu tiên, bạn nên áp dụng tất cả các lần di chuyển để đảm bảo cơ sở dữ liệu của bạn chứa các bảng cần thiết cho các tính năng mà bạn có thể chấp nhận, như xác thực người dùng và phiên.
Thay đổi mô hình
Mô hình của bạn không được đặt trong đá. Các mô hình của bạn sẽ thay đổi khi dự án Django của bạn có nhiều tính năng hơn. Bạn có thể thêm hoặc xóa các trường hoặc thay đổi loại và tùy chọn của chúng.
Khi bạn thay đổi định nghĩa của một mô hình, các bảng cơ sở dữ liệu được sử dụng để lưu trữ các mô hình này cũng phải được thay đổi. Nếu các định nghĩa mô hình của bạn không khớp với lược đồ cơ sở dữ liệu hiện tại, rất có thể bạn sẽ gặp phải django.db.utils.OperationalError .
Vì vậy, làm thế nào để bạn thay đổi các bảng cơ sở dữ liệu? Bằng cách tạo và áp dụng quá trình di chuyển.
Trong khi kiểm tra trình theo dõi Bitcoin của mình, bạn nhận ra rằng mình đã mắc sai lầm. Mọi người đang bán các phần nhỏ của Bitcoin, vì vậy trường volume phải thuộc loại DecimalField thay vì PositiveIntegerField .
Hãy thay đổi mô hình để trông giống như sau:
class PriceHistory(models.Model):
date = models.DateTimeField(auto_now_add=True)
price = models.DecimalField(max_digits=7, decimal_places=2)
volume = models.DecimalField(max_digits=7, decimal_places=3)
Nếu không có di chuyển, bạn sẽ phải tìm ra cú pháp SQL để biến một PositiveIntegerField thành một DecimalField . May mắn thay, Django sẽ giải quyết điều đó cho bạn. Chỉ cần yêu cầu nó thực hiện di chuyển:
$ python manage.py makemigrations
Migrations for 'historical_data':
historical_data/migrations/0002_auto_20181112_1950.py
- Alter field volume on pricehistory
Lưu ý: Tên của tệp di chuyển (0002_auto_20181112_1950.py ) dựa trên thời điểm hiện tại và sẽ khác nếu bạn theo dõi trên hệ thống của mình.
Bây giờ bạn áp dụng quá trình di chuyển này vào cơ sở dữ liệu của mình:
$ python manage.py migrate
Operations to perform:
Apply all migrations: admin, auth, contenttypes, historical_data, sessions
Running migrations:
Applying historical_data.0002_auto_20181112_1950... OK
Quá trình di chuyển đã được áp dụng thành công, vì vậy bạn có thể sử dụng dbshell để xác minh rằng các thay đổi có ảnh hưởng:
$ python manage.py dbshell
SQLite version 3.19.3 2017-06-27 16:48:08
Enter ".help" for usage hints.
sqlite> .schema --indent historical_data_pricehistory
CREATE TABLE IF NOT EXISTS "historical_data_pricehistory" (
"id" integer NOT NULL PRIMARY KEY AUTOINCREMENT,
"date" datetime NOT NULL,
"price" decimal NOT NULL,
"volume" decimal NOT NULL
);
Nếu bạn so sánh lược đồ mới với lược đồ bạn đã thấy trước đó, bạn sẽ nhận thấy rằng loại của volume cột đã thay đổi từ integer thành decimal để phản ánh sự thay đổi của volume trường trong mô hình từ PositiveIntegerField thành DecimalField .
Liệt kê các cuộc di chuyển
Nếu bạn muốn biết những di chuyển nào tồn tại trong dự án Django, bạn không cần phải tìm hiểu sâu về migrations thư mục của các ứng dụng đã cài đặt của bạn. Bạn có thể sử dụng showmigrations lệnh:
$ ./manage.py showmigrations
admin
[X] 0001_initial
[X] 0002_logentry_remove_auto_add
[X] 0003_logentry_add_action_flag_choices
auth
[X] 0001_initial
[X] 0002_alter_permission_name_max_length
[X] 0003_alter_user_email_max_length
[X] 0004_alter_user_username_opts
[X] 0005_alter_user_last_login_null
[X] 0006_require_contenttypes_0002
[X] 0007_alter_validators_add_error_messages
[X] 0008_alter_user_username_max_length
[X] 0009_alter_user_last_name_max_length
contenttypes
[X] 0001_initial
[X] 0002_remove_content_type_name
historical_data
[X] 0001_initial
[X] 0002_auto_20181112_1950
sessions
[X] 0001_initial
Danh sách này liệt kê tất cả các ứng dụng trong dự án và các di chuyển được liên kết với từng ứng dụng. Ngoài ra, nó sẽ đặt một X lớn bên cạnh các di chuyển đã được áp dụng.
Đối với ví dụ nhỏ của chúng tôi, showmigrations Lệnh không phải là đặc biệt thú vị, nhưng nó rất hữu ích khi bạn bắt đầu làm việc trên cơ sở mã hiện có hoặc làm việc trong một nhóm mà bạn không phải là người duy nhất thêm di chuyển.
Di chuyển không được áp dụng
Bây giờ bạn biết cách thực hiện các thay đổi đối với lược đồ cơ sở dữ liệu của mình bằng cách tạo và áp dụng các phép di chuyển. Tại một số thời điểm, bạn có thể muốn hoàn tác các thay đổi và chuyển trở lại lược đồ cơ sở dữ liệu cũ hơn vì bạn:
- Muốn kiểm tra quá trình di chuyển mà một đồng nghiệp đã viết
- Nhận ra rằng một thay đổi bạn đã thực hiện là một ý tưởng tồi
- Làm việc song song trên nhiều tính năng với các thay đổi cơ sở dữ liệu khác nhau
- Muốn khôi phục một bản sao lưu đã được tạo khi cơ sở dữ liệu vẫn còn một lược đồ cũ hơn
May mắn thay, việc di chuyển không phải là con đường một chiều. Trong nhiều trường hợp, tác động của quá trình di chuyển có thể được hoàn tác bằng cách hủy áp dụng quá trình di chuyển. Để hủy áp dụng quá trình di chuyển, bạn phải gọi migrate với tên của ứng dụng và tên của lần di chuyển trước đó sự di chuyển bạn muốn bỏ áp dụng.
Nếu bạn muốn hoàn nguyên quá trình di chuyển 0002_auto_20181112_1950 trong historical_data của bạn ứng dụng, bạn phải vượt qua 0001_initial làm đối số cho migrations lệnh:
$ python manage.py migrate historical_data 0001_initial
Operations to perform:
Target specific migration: 0001_initial, from historical_data
Running migrations:
Rendering model states... DONE
Unapplying historical_data.0002_auto_20181112_1950... OK
Quá trình di chuyển chưa được áp dụng, có nghĩa là các thay đổi đối với cơ sở dữ liệu đã được hoàn nguyên.
Việc không áp dụng quá trình di chuyển sẽ không xóa tệp di chuyển của nó. Lần tiếp theo bạn chạy migrations lệnh, quá trình di chuyển sẽ được áp dụng lại.
Thận trọng: Đừng nhầm lẫn giữa việc di chuyển không được áp dụng với thao tác hoàn tác mà bạn đã quen từ trình soạn thảo văn bản yêu thích của mình.
Không phải tất cả các hoạt động cơ sở dữ liệu có thể được hoàn nguyên hoàn toàn. Nếu bạn xóa một trường khỏi một mô hình, tạo một di chuyển và áp dụng nó, Django sẽ xóa cột tương ứng khỏi cơ sở dữ liệu.
Việc không áp dụng quá trình di chuyển đó sẽ tạo lại cột, nhưng nó sẽ không trả lại dữ liệu đã được lưu trữ trong cột đó!
Khi bạn đang xử lý các tên di chuyển, Django sẽ tiết kiệm cho bạn một vài lần nhấn phím bằng cách không bắt bạn viết chính tả toàn bộ tên của quá trình di chuyển. Nó chỉ cần đủ tên để xác định nó duy nhất.
Trong ví dụ trước, chỉ cần chạy python manage.py migrate historical_data 0001 là đủ .
Chuyển đổi đặt tên
Trong ví dụ trên, Django đã nghĩ ra tên cho quá trình di chuyển dựa trên dấu thời gian — một cái gì đó giống như *0002_auto_20181112_1950 . Nếu không hài lòng với điều đó, bạn có thể sử dụng --name để cung cấp tên tùy chỉnh (không có .py phần mở rộng).
Để thử điều đó, trước tiên bạn phải xóa quá trình di chuyển cũ. Bạn đã không áp dụng nó, vì vậy bạn có thể xóa tệp một cách an toàn:
$ rm historical_data/migrations/0002_auto_20181112_1950.py
Bây giờ bạn có thể tạo lại nó với một tên mô tả hơn:
$ ./manage.py makemigrations historical_data --name switch_to_decimals
Thao tác này sẽ tạo quá trình di chuyển giống như trước đây ngoại trừ tên mới là 0002_switch_to_decimals .
Kết luận
Bạn đã trình bày khá nhiều thông tin cơ bản trong hướng dẫn này và đã học được các nguyên tắc cơ bản của việc di chuyển Django.
Tóm lại, các bước cơ bản để sử dụng di chuyển Django trông như sau:
- Tạo hoặc cập nhật một mô hình
- Chạy
./manage.py makemigrations <app_name> - Chạy
./manage.py migrateđể di chuyển mọi thứ hoặc./manage.py migrate <app_name>để di chuyển một ứng dụng riêng lẻ - Lặp lại nếu cần
Đó là nó! Quy trình làm việc này sẽ hoạt động trong phần lớn thời gian, nhưng nếu mọi thứ không diễn ra như mong đợi, bạn cũng biết cách liệt kê và hủy áp dụng các di chuyển.
Nếu trước đây bạn đã tạo và sửa đổi các bảng cơ sở dữ liệu của mình bằng SQL viết tay, thì giờ đây, bạn đã trở nên hiệu quả hơn nhiều bằng cách ủy quyền công việc này cho việc di chuyển Django.
Trong hướng dẫn tiếp theo của loạt bài này, bạn sẽ đi sâu hơn vào chủ đề và tìm hiểu cách hoạt động của Django Migrations.
Tiền thưởng miễn phí: Nhấp vào đây để có quyền truy cập vào Hướng dẫn tài nguyên học tập Django (PDF) miễn phí chỉ cho bạn các mẹo và thủ thuật cũng như các cạm bẫy thường gặp cần tránh khi xây dựng ứng dụng web Python + Django.
Chúc mừng!
