گزینه های متا گزینه

این سند تمام گزینه های فراداده ممکن را توضیح می دهد که می توانید مدل خود را در متا کلاس داخلی خود ارائه دهید.

گزینه های متا موجود

خلاصه ¶

اگر انتزاعی = درست باشد ، این مدل یک کلاس پایه انتزاعی خواهد بود.

app_label

اگر یک مدل در خارج از یک برنامه در install_apps تعریف شده باشد ، باید اعلام کند که کدام برنامه متعلق به آن است:

اگر می خواهید یک مدل با فرمت App_Label. Object_Name یا APP_LABEL. MODEL_NAME را نمایندگی کنید ، می توانید به ترتیب از Model. _meta. label یا Model. _meta. label_lower استفاده کنید.

base_manager_name

به عنوان مثال ، نام ویژگی مدیر ، "اشیاء" ، برای استفاده برای مدل _base_manager.

db_table

نام جدول پایگاه داده برای استفاده برای مدل:

نام جدول

برای صرفه جویی در وقت ، Django به طور خودکار نام جدول پایگاه داده را از نام کلاس مدل شما و برنامه ای که حاوی آن است ، استخراج می کند. نام جدول پایگاه داده یک مدل با پیوستن به "برچسب برنامه" مدل - نامی که در مدیریت استفاده کرده اید - StartApp - به نام کلاس مدل ، با تأکید بین آنها ساخته شده است.

به عنوان مثال ، اگر یک کتابفروشی برنامه (همانطور که توسط Manage. Py StartApp Bookstore ایجاد شده است) دارید ، مدلی که به عنوان کتاب کلاس تعریف شده است ، دارای یک جدول پایگاه داده به نام Bookstore_Book خواهد بود.

برای نادیده گرفتن نام جدول پایگاه داده ، از پارامتر db_table در کلاس متا استفاده کنید.

اگر نام جدول پایگاه داده شما یک کلمه محفوظ SQL است ، یا دارای کاراکترهایی است که در نامهای متغیر پایتون مجاز نیستند - به ویژه ، Hyphen - خوب است. Django به نقل از ستون و جدول در پشت صحنه.

از نام جدول های کوچک برای Mariadb و MySQL استفاده کنید

به شدت توصیه می شود که هنگام نادیده گرفتن نام جدول از طریق db_table ، از نام جدول های کوچک استفاده کنید ، به خصوص اگر از backend mysql استفاده می کنید. برای اطلاعات بیشتر به یادداشت های MySQL مراجعه کنید.

نام جدول برای اوراکل

به منظور دیدار با محدودیت 30 بار Oracle در نام جدول ، و با کنوانسیون های معمول برای پایگاه داده های اوراکل مطابقت دارد ، ممکن است Django نام جدول را کوتاه کند و آنها را تمام کند. برای جلوگیری از چنین تحولات ، از یک نام نقل شده به عنوان مقدار db_table استفاده کنید:

چنین نامهای نقل شده ای نیز می تواند با سایر پایگاه داده های پشتیبانی شده Django مورد استفاده قرار گیرد. به جز اوراکل ، نقل قول ها هیچ تاثیری ندارند. برای جزئیات بیشتر به یادداشت های اوراکل مراجعه کنید.

db_tablespace

نام جدول دیتابیس برای استفاده برای این مدل. در صورت تنظیم ، پیش فرض تنظیم پیش فرض_tablespace پروژه است. اگر پس زمینه از سفره ها پشتیبانی نمی کند ، این گزینه نادیده گرفته می شود.

Default_Manager_name

نام مدیر برای استفاده برای مدل _default_manager.

Default_related_name

نامی که به طور پیش فرض برای رابطه از یک شیء مرتبط به این یکی استفاده می شود. پیش فرض _set است.

از آنجا که نام معکوس برای یک فیلد باید منحصر به فرد باشد ، اگر قصد دارید مدل خود را زیر طبقه بندی کنید ، مراقب باشید. برای کار در مورد تصادفات نام ، بخشی از نام باید حاوی "٪ (app_label) s و" ٪ (model_name) s "باشد که به ترتیب با نام برنامه ای که مدل در آن قرار دارد جایگزین می شود و نام مدلهر دو پایینبرای مدل های انتزاعی به پاراگراف نام های مرتبط مراجعه کنید.

get_latest_by

نام یک فیلد یا لیستی از نام های فیلد در مدل ، به طور معمول Datefield ، DateTimefield یا Integerfield. این زمینه (های) پیش فرض را برای استفاده در آخرین روشهای () و اولین روشهای مدیر مدل شما مشخص می کند.

برای اطلاعات بیشتر به آخرین اسناد () مراجعه کنید.

اداره می شود ¶

پیش فرض درست ، به این معنی که Django جداول پایگاه داده مناسب را در مهاجرت یا به عنوان بخشی از مهاجرت ایجاد می کند و آنها را به عنوان بخشی از یک دستور مدیریت Flush حذف می کند. یعنی ، Django مدیریت چرخه عمر میزهای پایگاه داده را مدیریت می کند.

اگر نادرست باشد ، هیچ کار ایجاد ، اصلاح یا عملیات حذف برای این مدل انجام نمی شود. این امر مفید است اگر مدل یک جدول موجود یا نمای پایگاه داده ای را که با برخی از روش های دیگر ایجاد شده است ، نشان دهد. این تنها تفاوت در هنگام مدیریت = نادرست است. تمام جنبه های دیگر استفاده از مدل دقیقاً مشابه با حالت عادی است. این شامل

اگر آن را اعلام نکردید ، یک قسمت کلید اصلی اتوماتیک به مدل اضافه کنید. برای جلوگیری از سردرگمی برای خوانندگان کد بعدی ، توصیه می شود تمام ستون ها را از جدول پایگاه داده ای که هنگام استفاده از مدل های کنترل نشده مدل می کنید ، مشخص کنید.

اگر مدلی با مدیریت = false حاوی Mantomanyfield باشد که به یک مدل بدون کنترل دیگر اشاره می کند ، جدول میانی برای پیوستن به بسیاری از افراد نیز ایجاد نمی شود. با این حال ، جدول واسطه ای بین یک مدل مدیریت شده و یک مدل بدون کنترل ایجاد می شود.

اگر شما نیاز به تغییر این رفتار پیش فرض دارید ، جدول واسطه را به عنوان یک مدل صریح (با مجموعه مدیریت شده در صورت لزوم) ایجاد کنید و از ویژگی ManyTomanyfield استفاده کنید.

برای تست های مربوط به مدل هایی با مدیریت = false ، این وظیفه شماست که اطمینان حاصل کنید که جداول صحیح به عنوان بخشی از تنظیمات تست ایجاد شده است.

اگر علاقه مند به تغییر رفتار سطح پایتون یک کلاس مدل هستید ، می توانید از مدیریت شده = false استفاده کرده و یک نسخه از یک مدل موجود ایجاد کنید. با این حال ، یک رویکرد بهتر برای آن وضعیت وجود دارد: مدل های پروکسی.

order_with_respect_to

این شیء را با توجه به حوزه داده شده ، معمولاً یک کلید خارجی ، مرتب می کند. این می تواند مورد استفاده قرار گیرد تا اشیاء مرتبط با توجه به شیء والدین قابل ترتیب باشد. به عنوان مثال ، اگر یک پاسخ به یک موضوع سؤال مربوط می شود ، و یک سؤال بیش از یک پاسخ دارد و ترتیب پاسخ ها مهم است ، شما این کار را می کنید:

هنگامی که order_with_respect_to تنظیم شده است ، دو روش اضافی برای بازیابی و تنظیم ترتیب اشیاء مرتبط ارائه شده است: get_related_order () و set_related_order () ، جایی که مرتبط با نام مدل پایین است. به عنوان مثال ، با فرض اینکه یک شیء سؤال دارای چندین اشیاء پاسخ مرتبط است ، لیست برگشتی حاوی کلیدهای اصلی اشیاء پاسخ مرتبط است:

ترتیب پاسخهای مرتبط با شیء یک سؤال را می توان با انتقال لیستی از کلیدهای اصلی پاسخ تنظیم کرد:

اشیاء مرتبط همچنین دو روش دریافت می کنند ، get_next_in_order () و get_previous_in_order () ، که می تواند برای دسترسی به آن اشیاء به ترتیب مناسب آنها استفاده شود. با فرض اینکه اشیاء پاسخ توسط شناسه سفارش داده می شوند:

order_with_respect_to به طور ضمنی گزینه سفارش را تنظیم می کند

در داخل ، order_with_respect_to یک ستون/پایگاه داده اضافی به نام _order اضافه می کند و گزینه سفارش مدل را به این قسمت تنظیم می کند. در نتیجه ، order_with_respect_to و سفارش را نمی توان با هم استفاده کرد ، و سفارش اضافه شده توسط order_with_respect_to هر زمان که لیستی از اشیاء این مدل بدست آورید اعمال می شود.

از آنجا که order_with_respect_to یک ستون پایگاه داده جدید اضافه می کند ، در صورت اضافه کردن یا تغییر سفارش_ با with_respect_to پس از مهاجرت اولیه ، حتماً مهاجرت های مناسب را انجام داده و اعمال کنید.

مرتب سازی ¶

سفارش پیش فرض برای شی ، برای استفاده در هنگام بدست آوردن لیست اشیاء:

این یک لیست یا لیستی از رشته ها و/یا عبارات پرس و جو است. هر رشته یک نام فیلد با پیشوند "-" اختیاری است ، که نشانگر ترتیب نزولی است. زمینه های بدون "-" صعودی سفارش داده می شود. از رشته "؟" استفاده کنیدبرای سفارش تصادفی.

به عنوان مثال ، برای سفارش توسط یک قسمت صعودی pub_date ، از این استفاده کنید:

برای سفارش توسط pub_date نزولی ، از این استفاده کنید:

برای سفارش توسط pub_date نزولی ، سپس توسط نویسنده صعود ، از این استفاده کنید:

همچنین می توانید از عبارات پرس و جو استفاده کنید. برای سفارش توسط نویسنده صعود و مرتب سازی مقادیر تهی ، از این استفاده کنید:

سفارش یک عملیات رایگان نیست. هر زمینه ای که به سفارش اضافه می کنید ، هزینه ای را برای پایگاه داده شما متحمل می شود. هر کلید خارجی که اضافه می کنید به طور ضمنی شامل تمام سفارشات پیش فرض آن نیز خواهد بود.

اگر یک پرس و جو مشخص شده مشخص نشده باشد ، نتایج به ترتیب نامشخص از پایگاه داده بازگردانده می شود. یک سفارش خاص فقط در هنگام سفارش توسط مجموعه ای از زمینه هایی که به طور منحصر به فرد هر شی را در نتایج شناسایی می کنند ، تضمین می شود. به عنوان مثال ، اگر یک قسمت نام منحصر به فرد نیست ، سفارش توسط آن اشیاء با همین نام را تضمین نمی کند همیشه به همان ترتیب ظاهر می شود.

مجوزها

مجوزهای اضافی برای ورود به جدول مجوزها هنگام ایجاد این شی. اضافه کردن ، تغییر ، حذف و مشاهده مجوزها به طور خودکار برای هر مدل ایجاد می شود. این مثال مجوز اضافی را مشخص می کند ، CAN_DELIVER_PIZZAS:

این یک لیست یا Tuple از 2 عکس در قالب است (permission_code ، human_readable_permission_name).

Default_permissions

پیش فرض به ("افزودن" ، "تغییر" ، "حذف" ، "مشاهده"). اگر برنامه شما نیازی به مجوزهای پیش فرض ندارد ، می توانید این لیست را به عنوان مثال با تنظیم این لیست در لیست خالی تنظیم کنید. قبل از ایجاد مدل توسط مهاجرت ، باید در مدل مشخص شود تا از ایجاد مجوزهای حذف شده جلوگیری شود.

پروکسی

اگر پروکسی = درست باشد ، مدلی که مدل دیگری را زیر کلاس می گذارد ، به عنوان یک مدل پروکسی رفتار می شود.

مورد نیاز_ db_features

لیست ویژگی های بانک اطلاعاتی که اتصال فعلی باید داشته باشد به گونه ای که مدل در مرحله مهاجرت در نظر گرفته شود. به عنوان مثال ، اگر این لیست را روی ['GIS_ENABLED'] تنظیم کنید ، این مدل فقط در پایگاه داده های دارای قابلیت GIS همگام سازی می شود. همچنین در هنگام تست با چندین پشتیبان پایگاه داده ، برخی از مدل ها را پرش کنید. از روابط بین مدلهایی که ممکن است یا ممکن است ایجاد شود ، خودداری کنید زیرا ORM این کار را نمی کند.

مورد نیاز_ db_vendor

نام یک فروشنده پایگاه داده پشتیبانی شده که این مدل خاص است. نام های فعلی فروشنده داخلی عبارتند از: SQLITE ، PostgreSQL ، MySQL ، Oracle. اگر این ویژگی خالی نباشد و فروشنده اتصال فعلی با آن مطابقت نداشته باشد ، مدل هماهنگ نمی شود.

select_on_save

تعیین می کند که آیا Django از الگوریتم Pre-1. 6 django. db. models. model. save () استفاده خواهد کرد. الگوریتم قدیمی از SELECT برای تعیین اینکه آیا یک ردیف موجود برای به روزرسانی وجود دارد ، استفاده می کند. الگوریتم جدید به روزرسانی را مستقیماً امتحان می کند. در بعضی موارد نادر ، به روزرسانی یک ردیف موجود برای Django قابل مشاهده نیست. به عنوان مثال ، PostgreSQL در Trigger Update است که NULL را برمی گرداند. در چنین مواردی ، الگوریتم جدید حتی اگر یک ردیف در پایگاه داده وجود داشته باشد ، درج می شود.

معمولاً نیازی به تنظیم این ویژگی نیست. حالت پیش فرض غلط است .

برای اطلاعات بیشتر در مورد الگوریتم ذخیره قدیمی و جدید ، به django. db. models. model. save () مراجعه کنید.