محتوای آموزشی وبلاگ نت‌آرام
پس از انتقال سایت جنگو یا اضافه‌کردن یک بخش جدید، صفحه خطایی مانند
no such table: shop_order نشان می‌دهد. این پیام معمولاً از SQLite می‌آید و می‌گوید در پایگاه داده‌ای که درخواست از آن استفاده کرده، جدول مورد انتظار پیدا نشده است. جدول ممکن است هنوز ساخته نشده باشد، برنامه به دیتابیس دیگری وصل شده باشد یا نسخه فایل‌های migration با نسخه کد هماهنگ نباشد.قبل از اجرای فرمانی که ساختار پایگاه داده را تغییر می‌دهد، هویت دیتابیس و وضعیت migration را مشخص می‌کنیم. حذف دیتابیس، پاک‌کردن همه فایل‌های migration یا استفاده از
--fake برای ساکت‌کردن پیام می‌تواند داده و تاریخچه را ناسازگار کند.۱. نام جدول و زمان وقوع خطا را ثبت کنید
در گزارش خصوصی برنامه، نام کامل جدول و مسیری را که خطا داده ببینید. اگر برنامه هنگام بازشدن صفحه عمومی خطای ۵۰۰ نشان می‌دهد، برای خواندن جزئیات از لاگ سرویس استفاده کنید؛ Debug را روی سایت عمومی روشن نکنید. پیام SQLite با خطاهای مشابه MySQL یا PostgreSQL از نظر واژه و جزئیات تفاوت دارد، ولی اصل بررسی «کدام دیتابیس و کدام جدول» در همه آن‌ها مهم است.
قبل از هر تغییری از پایگاه داده و نسخه فعلی کد، یک پشتیبان سازگار و قابل بازیابی داشته باشید. برای SQLite فعال، روش پشتیبان آنلاین یا روش تأییدشده میزبان را انتخاب کنید؛ کپی عجولانه فایل در زمان نوشتن ممکن است نسخه کامل موردنیاز را ندهد. برای MySQL یا PostgreSQL از روش پشتیبان مناسب همان موتور استفاده کنید.
۲. پروژه و دیتابیس واقعی را مشخص کنید
در cPanel بخش برنامه پایتون را باز کنید و مسیر Application root و فرمان ورود به محیط مجازی برنامه را از همان صفحه بگیرید. در Terminal یا SSH، محیط درست را فعال کنید و به پوشه دارای
کد / دستورmanage.py بروید:cd ~/myproject
pwd
ls -la manage.py
python --version
مسیر نمونه را با مسیر واقعی عوض کنید. حال موتور و نام تنظیم‌شده دیتابیس پیش‌فرض را ببینید:
کد / دستورpython manage.py shell -c 'from django.conf import settings; d=settings.DATABASES["default"]; print("settings:", settings.SETTINGS_MODULE); print("engine:", d["ENGINE"]); print("name:", d["NAME"])'
اگر SQLite است،
NAME معمولاً مسیر فایل دیتابیس را نشان می‌دهد. وجود دو فایل با نام مشابه در پوشه‌های مختلف یا تغییر مسیر بعد از انتقال می‌تواند باعث اتصال به نسخه خالی شود. مسیر را با نسخه سالم و تنظیمات برنامه وب مقایسه کنید. این خروجی ممکن است نام خصوصی دیتابیس یا مسیر حساب را نشان دهد، پس آن را عمومی نکنید.در پروژه چنددیتابیسی، جدول ممکن است در alias دیگری تعریف شده باشد. فرمان‌های ادامه برای alias پیش‌فرض‌اند؛ در صورت استفاده از alias دیگر، نام درست و روترهای پایگاه داده پروژه باید به‌طور جداگانه بررسی شوند. محیط ترمینال و وب‌سرور نیز ممکن است متغیرهای متفاوتی داشته باشند.
۳. جدول واقعی و تاریخچه migration را مقایسه کنید
برای دیدن نام جدول‌های قابل مشاهده از اتصال پیش‌فرض Django:
کد / دستورpython manage.py shell -c 'from django.db import connection; print(*connection.introspection.table_names(), sep="\n")'
خروجی فهرست جدول‌هاست و می‌تواند ساختار داخلی برنامه را آشکار کند. اگر جدول موردنظر در همین اتصال نیست، قدم بعدی وضعیت migration آن برنامه است. فرض کنیم نام برنامه جنگو
کد / دستورshop است؛ نام واقعی خود را جایگزین کنید:python manage.py showmigrations shop --database=default
python manage.py migrate --plan --database=default
در خروجی
showmigrations علامت [X] نشان می‌دهد آن migration در تاریخچه دیتابیس انتخاب‌شده ثبت شده و `` یعنی در همان تاریخچه ثبت نشده است. خروجی --plan کارهای پیشنهادی migrate را پیش‌نمایش می‌دهد. هر دو فرمان را برای محیط و نسخه درست بخوانید؛ نشان‌دادن [X] به‌تنهایی ثابت نمی‌کند جدول در اثر تغییر دستی یا بازیابی ناقص هنوز واقعاً وجود دارد.اگر برنامه یا فایل migration پیدا نمی‌شود، ابتدا ببینید کد کامل همان نسخه منتقل شده و برنامه در
INSTALLED_APPS قرار دارد یا نه. فایل‌های migration موجود در مخزن را پاک یا دوباره تولید نکنید. اگر نسخه‌ای از آن‌ها در انتقال جا مانده، نسخه دقیق تأییدشده پروژه را بازگردانید و دوباره وضعیت را ببینید.۴. اگر migration اجرا نشده است
وقتی مطمئن شدید به دیتابیس درست متصلید، فایل‌های migration با نسخه برنامه هم‌خوان‌اند، برنامه اجرا و نتیجه plan را بررسی کرده‌اید و نسخه پشتیبان قابل بازیابی دارید، ابتدا عملیات را روی کپی آزمایشی انجام دهید. فرمان متداول برای اعمال migrationهای معوق:
کد / دستورpython manage.py migrate --database=default
این فرمان ساختار دیتابیس را تغییر می‌دهد و بعضی migrationها می‌توانند داده را نیز جابه‌جا یا حذف کنند. بنابراین آن را بدون خواندن طرح و پشتیبان روی تنها نسخه داده زنده اجرا نکنید. در خروجی به نام migrationها و خطاهای احتمالی توجه کنید. اگر برنامه دیگری به همان دیتابیس متصل است، زمان‌بندی و سازگاری نسخه‌ها را نیز در نظر بگیرید.
پس از اجرای موفق،
showmigrations و فهرست جدول‌ها را دوباره بخوانید و مسیر مشکل‌دار را با داده آزمایشی امتحان کنید. برای هاست اشتراکی، اگر برنامه با محیط جداگانه وب اجرا می‌شود، بعد از انتشار و بررسی تنظیمات، همان برنامه را از پنل Restart کنید.۵. اگر تاریخچه اجراشده است اما جدول وجود ندارد
در این حالت ممکن است کد به دیتابیس اشتباه وصل باشد، جدول دستی حذف شده باشد یا نسخه پشتیبان ساختار و جدول تاریخچه با هم هماهنگ نباشند. ابتدا هویت دیتابیس، نام جدول در خطا و نسخه بازیابی‌شده را مقایسه کنید. اجرای
migrate --fake، پاک‌کردن رکوردهای تاریخچه یا حذف جدول‌های موجود بدون تحلیل می‌تواند وضعیت را پیچیده‌تر کند. روی نسخه کپی‌شده و با پشتیبان، علت ناسازگاری و مسیر بازیابی درست را بررسی کنید.اگر خطا بعد از تغییر مدل رخ داده ولی اصلاً فایل migration مناسب در مخزن وجود ندارد، توسعه‌دهنده باید تغییر مدل و ساخت migration را در محیط توسعه بررسی، فایل تولیدشده را بازبینی و همراه نسخه تأییدشده منتشر کند. ساخت migration روی محیط تولید به‌صورت عجولانه ممکن است با تاریخچه سایر محیط‌ها ناسازگار شود.
۶. نتیجه را تا پایان کار بررسی کنید
جدول موردنظر را در اتصال درست، وضعیت migration و عملکرد همان صفحه یا عملیات واقعی بررسی کنید. اگر خطا به
database is locked تغییر کرده، مشکل از نوع دیگری است و راهنمای قفل SQLite کمک می‌کند. نسخه پشتیبان را تا تأیید بازیابی و پایان دوره بازگشت نگه دارید.برای اجرای پروژه‌های سازگار، صفحه هاست پایتون نت‌آرام و برای جزئیات فرمان‌ها، مستندات رسمی مدیریت Django را ببینید.
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام