Forwarded from TorhamDev | تورهام 😳
TorhamDev | تورهام 😳
سر این پروژه یکچیزی هم درباره جنگو یاد گرفتم. مسئله: نیاز داریم یک فیلد به مدل دیفالت جنگو اضافه کنیم چون اورایت کردنش nmt حال ندارم. جواب: خب چندتا حالت میشه اینکار کرد، اول اینکه یک مدل جدا بزنید فارنکی با one2one فیلد کنید به مدل اصلی جنگو یا اینکه AbestractUser…
رفرنس داکیومنت به این ماجرا
داکیومنتش بخونید دانا و نابغه بشید:)
داکیومنتش بخونید دانا و نابغه بشید:)
👍1
Forwarded from TorhamDev | تورهام 😳
TorhamDev | تورهام 😳
رفرنس داکیومنت به این ماجرا داکیومنتش بخونید دانا و نابغه بشید:)
جالبه همین خط اول عکس اول بخونید، توصیه جنگو اینه که هر پروژهای میزنید حتی اگه مدل دیفالت نیازهاتون برطرف میکنه بهتر مدل خودتون بسازید و معرفی کنید.
👍1
Django QuerySet - only() vs defer() vs exclude()
If you have some fields in your Django model that contain a lot of data and you don't need those fields for a particular query, you can tell Django not to retrieve them with defer():
While defer() works at the attribute level, exclude() works on the row level.
In other words, exclude() arguments are used after the WHERE clause -- i.e., SELECT * FROM users WHERE name = 'jan' -- while defer() changes * to the provided fields -- i.e., SELECT name, email FROM users.
Opposite to defer() is only(). If you have fewer fields that you want to retrieve than those you don't, you can use only() to retrieve only the fields provided as arguments:
If you have some fields in your Django model that contain a lot of data and you don't need those fields for a particular query, you can tell Django not to retrieve them with defer():
Event.objects.defer("denoscription") While defer() works at the attribute level, exclude() works on the row level.
In other words, exclude() arguments are used after the WHERE clause -- i.e., SELECT * FROM users WHERE name = 'jan' -- while defer() changes * to the provided fields -- i.e., SELECT name, email FROM users.
Opposite to defer() is only(). If you have fewer fields that you want to retrieve than those you don't, you can use only() to retrieve only the fields provided as arguments:
Event.objects.only("noscript")testdriven.io
Django QuerySet - only() vs defer() vs exclude()
👍2
Forwarded from TorhamDev | تورهام 😳
TorhamDev | تورهام 😳
نکته رندوم درباره orm #جنگو @TorhamDevCH
ماجرا اینه که زمانی که شما objects.get میزنید درحقیقت دارید همچین کوئری میسازید:
و بعد وقتی پشت سرش .delete() میزنید اتفاقی که میوفته اول کوئری select رو میزنه دیتا رو میگیره و بعد دوباره کوئری delete رو میزنه.
تو حالت دوم که از filter استفاده میکنید دیگه یک راست میاد کوئری دلیت رو میزنه و دیگه گت نمیکنه در نتیجه اگر دیتا وجود هم نداشته باشه اروری نمیخورید چون خوب اصلا نگرفتیدش که ارور بخورید. در نهایت اگه تمام کارتون از یک دیتا اینه که حذفش کنید با filter.delete بزنید خیلی بهتره.
@TorhamDevCH
SELECT * FROM MyModel WHERE id=1
و بعد وقتی پشت سرش .delete() میزنید اتفاقی که میوفته اول کوئری select رو میزنه دیتا رو میگیره و بعد دوباره کوئری delete رو میزنه.
تو حالت دوم که از filter استفاده میکنید دیگه یک راست میاد کوئری دلیت رو میزنه و دیگه گت نمیکنه در نتیجه اگر دیتا وجود هم نداشته باشه اروری نمیخورید چون خوب اصلا نگرفتیدش که ارور بخورید. در نهایت اگه تمام کارتون از یک دیتا اینه که حذفش کنید با filter.delete بزنید خیلی بهتره.
@TorhamDevCH
👍5
TorhamDev | تورهام 😳
داخل جنگو ۳ نوع Model inheritance داریم. یعنی مدلهای دیتابیس میتونن به سه شکل از هم دیگه ارث بری کنند. ۱. Abstract base classes ۲. Multi-table inheritance ۳. Proxy models که فعلا با دوتا اول کار ندارم و احتمالا بدونید چی هستند. ولی سومی همیشه برای من گنگ…
Medium
Django Model Inheritance Best Practices
We developers often rush to add/modify models in order to fix something or achieve a specific goal without considering the impact of our…
👍2
Forwarded from TorhamDev | تورهام 😳
امروز یکسری حالات مختلف از teardown کردن تستها در pytest یاد گرفتم خوب بود هر کدوم کاربرد و جای خودش داره.
به سه حالت مختلف رسیدم. حالت اول زمانی که شما نیاز به یک resource دارید برای تستهاتون برای مثال اول لاگین کنید و بعدش ریکوئست بزنید. تو این مواقع بهتر که یک fixture داشته باشید که براتون لاگین کنه و وقتی کارتون تموم شد خودش لاگ اوت کنه.
به اون پروسه لاگاوت کردن میگن teardown یکدونه هم tear up داریم که پروسه لاگین کردن تو این مثاله. مقال دیگش میشه زمانی که نیاز دارید یک رکورد خاص داخل دیتابیس ساخته بشه و بعد از تست حذف بشه. به ساختنش میگن tear up به حذف کردنش میگن tear down.
خب حالا حال اول که fixture باشه.
داخل فیکسچرها pytest هرچیزی که بعد از yield بیارید teardown و هرچی که قبلش بیاد tearup.
حالت دوم شما یک مقدار از درون تست نیاز دارید برای tear down کردن. برای مثال شما یک تست دارید پست زدن داخل توییتر رو تست میکنه. شما برای teardown کردن این تست لازم دارید پست رو پاک کنید اما برای پاک کردنش نیاز به id اون پست دارید. اینجاس که شما یک مقدار لازم دارید که داخل خود تست ساخته شده.
برای این مورد به نظر من بهترین حالت در حال حاظر با دانش الان من استفاده از try-finally هستش.
اینجا فیکسچرهای شما که برای مثال twt_client هست براتون کلاین tear up و tear down میکنن به روش اول. و try-finally پستی که ساختید رو tear down میکنه. مهدی سینیور ما باشد گفت که یک فیکسچر بسازم که داخلش یک yeild خالی باشه و بعد از yeild از داخل یک متغیر گلوبال بیاد ایدی پست ها رو بخونه و همرو حذف کنه که برای این کار لازمه داخل هر تست هر وقت پست ساختیم اضافه اش کنید به اون متغیر که من به نظرم try finally بهتر بود در نتیجه همون زدم فرستادم تکلید :)
@TorhamDevCH
به سه حالت مختلف رسیدم. حالت اول زمانی که شما نیاز به یک resource دارید برای تستهاتون برای مثال اول لاگین کنید و بعدش ریکوئست بزنید. تو این مواقع بهتر که یک fixture داشته باشید که براتون لاگین کنه و وقتی کارتون تموم شد خودش لاگ اوت کنه.
به اون پروسه لاگاوت کردن میگن teardown یکدونه هم tear up داریم که پروسه لاگین کردن تو این مثاله. مقال دیگش میشه زمانی که نیاز دارید یک رکورد خاص داخل دیتابیس ساخته بشه و بعد از تست حذف بشه. به ساختنش میگن tear up به حذف کردنش میگن tear down.
خب حالا حال اول که fixture باشه.
import pytest
@pytest.fixture
def client() -> AuthedClient:
#login and etc
yeild client
client.logout()
داخل فیکسچرها pytest هرچیزی که بعد از yield بیارید teardown و هرچی که قبلش بیاد tearup.
حالت دوم شما یک مقدار از درون تست نیاز دارید برای tear down کردن. برای مثال شما یک تست دارید پست زدن داخل توییتر رو تست میکنه. شما برای teardown کردن این تست لازم دارید پست رو پاک کنید اما برای پاک کردنش نیاز به id اون پست دارید. اینجاس که شما یک مقدار لازم دارید که داخل خود تست ساخته شده.
برای این مورد به نظر من بهترین حالت در حال حاظر با دانش الان من استفاده از try-finally هستش.
def test_twt_post_create_success(twt_client):
post_id = None
try:
post = twt_client.post("Hello from test")
post_id = post.id
finally:
if post_id:
twt_client.remove_post(post_id)
اینجا فیکسچرهای شما که برای مثال twt_client هست براتون کلاین tear up و tear down میکنن به روش اول. و try-finally پستی که ساختید رو tear down میکنه. مهدی سینیور ما باشد گفت که یک فیکسچر بسازم که داخلش یک yeild خالی باشه و بعد از yeild از داخل یک متغیر گلوبال بیاد ایدی پست ها رو بخونه و همرو حذف کنه که برای این کار لازمه داخل هر تست هر وقت پست ساختیم اضافه اش کنید به اون متغیر که من به نظرم try finally بهتر بود در نتیجه همون زدم فرستادم تکلید :)
@TorhamDevCH
👍1
Forwarded from TorhamDev | تورهام 😳
یک چیز جالب دیروز درباره pytest خوندم داخل داکیومنتش و اینه که شما میتونید scope یک fixture رو داینامیک کنید نسبت به تستی که اجرا میکنید.
این مثال خود داکیومنت و همینطوری که میبینید اگه یک فانکشن(callable) به جای اسکوپ بدید پایتست اون اجرا میکنه و دوتا ورودی بهش میده و از خروجی اون برای scope استفاده میکنه.
@TorhamDevCH
def determine_scooe(fixture_name, config):
if config.getoption("--keep-containers", None)
return "session"
return "function"
@pytest.fixture(scope=datermine_scope)
def docker_container():
yield spwan_container()
این مثال خود داکیومنت و همینطوری که میبینید اگه یک فانکشن(callable) به جای اسکوپ بدید پایتست اون اجرا میکنه و دوتا ورودی بهش میده و از خروجی اون برای scope استفاده میکنه.
@TorhamDevCH
Forwarded from TorhamDev | تورهام 😳
یک چیز دیگه هم چند روزه میخواستم بنویسم دربارش. درباره functions.wraps
زمانی که یک دکوریتور مینویسید اگر از wraps استفاده نکنید باعث میشید سیگنچر فانکشنهایی که از دکوریتور استفاده میکنن تغییر کنه.
وقتی شما از این دکوریتور استفاده میکنید برای مثال:
در حقیقت دارید میگید
حالا اتفاقی که میوفته اینه که سیگنچر foo تغییر میکنه به logged یعنی اگر شما داک استرینگ foo بگیرید بعد دکوریت شدن توسط logged چیزی که خواهید دید داک استرینگ logged. میتونید داک استرینگ رو با داندرلاین doc بگیرید.
حالا اگر از @wraps استفاده کنید این اتفاق نمیوفته و سیگنچر فانکشن foo باقی خواهد موند.
اره خلاصه
@TorhamDevCH
زمانی که یک دکوریتور مینویسید اگر از wraps استفاده نکنید باعث میشید سیگنچر فانکشنهایی که از دکوریتور استفاده میکنن تغییر کنه.
def logged(func):
def with_logging(*args, **kwargs):
print(func.__name__ + " called")
return func(*args, **kwargs)
return with_logging
`
وقتی شما از این دکوریتور استفاده میکنید برای مثال:
@logged
def foo(x):
return x ** x
در حقیقت دارید میگید
def foo(x):
return x ** x
foo = logged(foo)
حالا اتفاقی که میوفته اینه که سیگنچر foo تغییر میکنه به logged یعنی اگر شما داک استرینگ foo بگیرید بعد دکوریت شدن توسط logged چیزی که خواهید دید داک استرینگ logged. میتونید داک استرینگ رو با داندرلاین doc بگیرید.
حالا اگر از @wraps استفاده کنید این اتفاق نمیوفته و سیگنچر فانکشن foo باقی خواهد موند.
from functools import wraps
def logged(func):
@wraps
def with_logging(*args, **kwargs):
print("logged")
return func(*args, **kwargs)
@logged
def foo(x):
return x * x
اره خلاصه
@TorhamDevCH
❤1