چطور توی یک فرم اگر یک فایل آپلود شده از یک فرمت خاص نبود ارور برگردونیم
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
class MagAttachmentForm(forms.ModelForm): class Meta: model = MagAttachment fields = '__all__' def clean_file(self): file = self.cleaned_data['file'] content_type = file.content_type if content_type == 'application/pdf': return file else: raise forms.ValidationError('فرمت pdf') |
Concurrency به وقتی گفته میشه چند تسک روی زمانهایی که با هم overlap دارن انجام میشن، نه اینکه لزوما در یک زمان انجام بشوند. مثل multitasking مثلا multi-thread
Parallelism یعنی وقتی واقعا کارها همزمان انجام میشن، مثلا 2 تا تسک روی دو تا CPU مجزا انجام می شوند Multi-Processing
این یک مثال واقعی از بهبود یک پروژه است. query اولیه به شکل زیر بود:
|
1 2 3 4 5 6 7 |
bss_branch = Branch.objects.get(name__iexact="bss").office_set.all() for el in bss_branch: for svc in el.services.all(): if svc in my_services: setattr(el, 'is_activated', True) break |
با ابزار django debug toolbar تعداد query های این تکه کد را مرور کردم و جاهایی که به سرور query زده میشود به این شکل است:
2. در خط for el in bss_branch: یک query به دیتابیس زده می شود.
3. در خط for svc in el.services.all(): یک query به دیتابیس زده میشود. یعنی اگر در bss_branch تعداد N المان وجود داشته باشد به ازای هر کدام یک query در این قسمت زده خواهد شد.
یعنی برای هر el که تعداد آن به اندازه bss_branch هست یک query جدید داریم
بنا براین در کد بالا یک query زده شده و branch ها استخراج شده (در قسمت 1) که ترجمه آن:
|
1 2 3 4 5 6 7 8 9 |
SELECT `branch`.`id`, `branch`.`name`, `branch`.`name_fixed`, `branch`.`title_en`, `branch`.`title_fa`, `branch`.`is_active` FROM `branch` WHERE `branch`.`name` LIKE 'bss' LIMIT 21 |
در قسمت دوم یک query زده شده و office های آن branch استخراج شده:
|
1 2 3 4 5 6 7 8 9 |
SELECT `office`.`id`, `office`.`name`, `office`.`name_fixed`, `office`.`title_en`, `office`.`title_fa`, `office`.`branch_id`, `office`.`is_active` FROM `office` WHERE `office`.`branch_id` = 2 |
در قسمت سوم به ازای هر کدام از office ها یک query زده شده و service های آن استخراج شده به عنوان مثال یکیش رو آوردم:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 |
SELECT `service`.`id`, `service`.`name`, `service`.`name_fixed`, `service`.`st`, `service`.`branch_id`, `service`.`office_id`, `service`.`company_object_id`, `service`.`managed_service_provider_id`, `service`.`development_service_provider_id`, `service`.`product`, `service`.`developer_id`, `service`.`persian_names`, `service`.`other_names`, `service`.`service_account_id`, `service`.`service_account_email`, `service`.`technician_id`, `service`.`service_manager_id`, `service`.`expert_id`, `service`.`arc_manager_id`, `service`.`arc_expert_id`, `service`.`description`, `service`.`active`, `service`.`domain`, `service`.`aspect`, `service`.`scope`, `service`.`service_nature`, `service`.`other_technical_representatives`, `service`.`other_vendor_emails`, `service`.`document_sender`, `service`.`document_sender_email`, `service`.`modules`, `service`.`service_status`, `service`.`description_and_approval`, `service`.`approver` FROM `service` WHERE `service`.`office_id` = 6 |
پس در مجموع N+1 درخواست دیتابیس query زدن شد.
حالا اینو بهینه میکنیم به کد زیر:
|
1 2 3 4 |
bss_branch = Branch.objects.get(name__iexact="bss").office_set.prefetch_related('services') for el in bss_branch: el.is_activated = any(svc in my_services for svc in el.services.all()) |
در این نمونه کد query های زیر را داریم:
query قسمت 1
|
1 2 3 4 5 6 7 8 9 |
SELECT `branch`.`id`, `branch`.`name`, `branch`.`name_fixed`, `branch`.`title_en`, `branch`.`title_fa`, `branch`.`is_active` FROM `branch` WHERE `branch`.`name` LIKE 'bss' LIMIT 21 |
query قسمت 2
|
1 2 3 4 5 6 7 8 9 |
SELECT `office`.`id`, `office`.`name`, `office`.`name_fixed`, `office`.`title_en`, `office`.`title_fa`, `office`.`branch_id`, `office`.`is_active` FROM `office` WHERE `office`.`branch_id` = 2 |
query قسمت 3
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 |
SELECT `service`.`id`, `service`.`name`, `service`.`name_fixed`, `service`.`st`, `service`.`branch_id`, `service`.`office_id`, `service`.`company_object_id`, `service`.`managed_service_provider_id`, `service`.`development_service_provider_id`, `service`.`product`, `service`.`developer_id`, `service`.`persian_names`, `service`.`other_names`, `service`.`service_account_id`, `service`.`service_account_email`, `service`.`technician_id`, `service`.`service_manager_id`, `service`.`expert_id`, `service`.`arc_manager_id`, `service`.`arc_expert_id`, `service`.`description`, `service`.`active`, `service`.`domain`, `service`.`aspect`, `service`.`scope`, `service`.`service_nature`, `service`.`other_technical_representatives`, `service`.`other_vendor_emails`, `service`.`document_sender`, `service`.`document_sender_email`, `service`.`modules`, `service`.`service_status`, `service`.`description_and_approval`, `service`.`approver` FROM `service` WHERE `service`.`office_id` IN (6, 7, 8, 9, 10) |
همانطور که توی کد بالا میبینید توی خط آخر تمامی query ها ادغام شده اند
بنابراین N+1 دستور query به 3 query تبدیل شد
. توی کد زیر بعد از ثبت کردن فرم اگر صفحه را رفرش کنیم همان فرم دوباره ثبت میشود.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
if request.POST and 'comment_form_submit' in request.POST: feedback_comment_form = FeedbackCommentForm(request.POST) if feedback_comment_form.is_valid(): body = feedback_comment_form.cleaned_data['body'] DocumentComment.objects.create( document=d, user=request.user, body=body, comment_datetime=datetime.datetime.now() ) context['comment_list'] = DocumentComment.objects.filter(document=d) DocumentLogger.log(request, d, 'ثبت کامنت ') messages.success(request, 'کامنت ثبت شد') return render(request, "man/documents/document-detail.html", context) |
مشکل در فروم جنگو این جوری توضیح داده شده است:
یعنی بعد از POST موفق باید فرم را redirect کنیم که با این کار صفحه جدید با GET فراخوانی میشود در نتیجه اگر رفرش کنیم باز هم در خواست GET ارسال میگردد. یعنی کد را به شکل زیر تغییر میدهیم.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
if request.POST and 'comment_form_submit' in request.POST: feedback_comment_form = FeedbackCommentForm(request.POST) if feedback_comment_form.is_valid(): body = feedback_comment_form.cleaned_data['body'] DocumentComment.objects.create( document=d, user=request.user, body=body, comment_datetime=datetime.datetime.now() ) context['comment_list'] = DocumentComment.objects.filter(document=d) DocumentLogger.log(request, d, 'ثبت کامنت ') messages.success(request, 'کامنت ثبت شد') url = reverse('man:management_documents_document_detail', args=[doc_id]) return HttpResponseRedirect(url) |
بهترین روش یادگیری یه فریم ورک خوندن کد خود فریم ورک و داکیومنت توی خود کد هست. برای serializer توی جنگو یک کامنت هست توی rest_framework/serializer.py که:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
class BaseSerializer(Field): """ The BaseSerializer class provides a minimal class which may be used for writing custom serializer implementations. Note that we strongly restrict the ordering of operations/properties that may be used on the serializer in order to enforce correct usage. In particular, if a `data=` argument is passed then: .is_valid() - Available. .initial_data - Available. .validated_data - Only available after calling `is_valid()` .errors - Only available after calling `is_valid()` .data - Only available after calling `is_valid()` If a `data=` argument is not passed then: .is_valid() - Not available. .initial_data - Not available. .validated_data - Not available. .errors - Not available. .data - Available. """ def __init__(self, instance=None, data=empty, **kwargs):. . . |
خیلی خوب توضیح میده که اگر به serializer پارامتر data رو پاس داده باشیم تابع is_valid قابل استفاده است. و initial_data هم در دسترس هست که همون دیتایی هست که به API پاس داده شده. بعد از is_valid این داده ورودی به valid شده تبدیل میشه که میتونیم توی validated_data ببینیم. مثلا اگر Id به object مربوطه تبدیل میشه. و errors و data هم در دسترس خواهد بود. data درواقع اون رکورد جدیدی هست که ایجاد شده است.
مثال زیر رو ببینید:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
def create(self, request, *args, **kwargs): serializer = self.get_serializer(data=request.data) if not serializer.is_valid(): return Response( {"errors": serializer.errors}, status.HTTP_400_BAD_REQUEST ) self.perform_create(serializer) print("-----------------------------") print(serializer.initial_data) print(serializer.validated_data) print(serializer.errors) print(serializer.data) create_update_related_chain(serializer.instance, False) return Response(serializer.data, status.HTTP_201_CREATED) |
میبینید که بعد serializer.is_valid() مقادیر مربوطه رو پرینت کردم.
مثال خروجی هم در ادامه میبینید:
|
1 2 3 4 5 |
----------------------------- {'provider': 159, 'consumer': 156, 'interface': 164, 'interface2': 161, 'protocol': 2, 'lt': 0, 'description': '', 'api': '', 'frequency': 0, 'ProviderVerified': False, 'ConsumerVerified': False, 'ESBVerified': False, 'api_gateway': False, 'active': False} OrderedDict({'provider': <Service: Active probe(pixip)>, 'consumer': <Service: AOTA(hasin)>, 'interface': <Service: Behsa Proxy(external)>, 'interface2': <Service: GFEP(external)>, 'protocol': <Protocol: SFTP>, 'lt': 0, 'description': '', 'api': '', 'frequency': 0.0, 'ProviderVerified': False, 'ConsumerVerified': False, 'ESBVerified': False, 'api_gateway': False, 'active': False}) {} {'id': 1303, 'provider': 159, 'provider_name': 'active_probe', 'consumer': 156, 'consumer_name': 'aota', 'interface': 164, 'interface_name': 'behsa_proxy', 'interface2': 161, 'interface2_name': 'gfep', 'protocol': 2, 'protocol_name': 'sftp', 'lt': 0, 'lt_display': 'COMMAND', 'description': '', 'api': '', 'frequency': 0.0, 'ProviderVerified': False, 'ConsumerVerified': False, 'ESBVerified': False, 'api_gateway': False, 'active': False} |
در کد زیر باگ نهفته ای وجود دارد. یک دکمه حذف یک ردیف از جدول وجود دارد که وقتی روی آن کلیک میکنیم. eventListener به آن اضافه میشود. باگ به این شکل از که به هر تعداد کلیک بر روی این دکمه EventListener اضافه میشود. تا زمانی که صفحه رفرش شود. این باگ موجب میشود که در نهایت به تعداد eventListener ها درخواست به سرور ارسال میشود.
|
1 2 3 4 5 6 7 |
function deleteLink(link_id){ console.log(link_id); const saveBtn = document.querySelector("#deleteModal .btn-primary"); saveBtn.addEventListener('click', () => { deleteRow(link_id) }) } |
برای حل این مشکل باید هر وقت خواستیم EventListener اضافه کنیم، قبلی را پاک کنیم.
|
1 2 3 4 5 6 7 8 9 |
function deleteLink(link_id){ const confirmBtn = document.querySelector("#deleteModal .btn-primary"); const newConfirmBtn = confirmBtn.cloneNode(true); confirmBtn.parentNode.replaceChild(newConfirmBtn, confirmBtn); newConfirmBtn.addEventListener('click', () => { deleteRow(link_id); }); } |
برای حل مشکل Asynchronous توی جاوااسکریپت. قبل از Promise برنامه نویس ها از callback استفاده میکردند که مشکلات زیادی داشته از جمله callback hell
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
getUserData(1, function(user) { getPostsByUser(user.id, function(posts) { getCommentsForPost(posts[0].id, function(comments) { console.log('Comments:', comments); }, function(error) { console.error('Error fetching comments:', error); }); }, function(error) { console.error('Error fetching posts:', error); }); }, function(error) { console.error('Error fetching user:', error); }); |
کد بالا رو در نظرم بگیرید. توی هر مرحله باید callback تودرتو نوشت که باعث میشه. کد کثیف و اگر توی کد داخلی باگی پیدا بشه پیدا کردن و فیکس کردنش سخته.
توی Promise میتونیم به صورت زنجیروار همه عملیاتها رو مدیریت کرد بجای ساختار تودرتو. گارانتی شده که یا عملیات موفق میشه و تابع resolve اجرا میشه یا عملیات ناموفق خواهد بود و تابع reject اجرا میشه. یعنی به راحتی میتونی تمامی حالات رو با تابع then و catch مدیریت کنیم. حتی اگر عملیات به دلیل کندی زیاد طول بکشه.
مثال بالا رو میتونیم زنجیری مدیریت کنیم
|
1 2 3 4 5 |
getUser(1) .then(user => getPosts(user.id)) .then(posts => getComments(posts[0].id)) .then(comments => console.log('Comments:', comments)) .catch(error => console.error('Error:', error)); |
یکی از کاربردهاش API call هست
|
1 2 3 4 |
fetch('https://jsonplaceholder.typicode.com/posts') .then(response => response.json()) .then(data => console.log('Posts:', data)) .catch(error => console.error('API Error:', error)); |
توی مثال زیر حتی چندین API با هم صدا زده میشه و میبینیم که چقدر خوانا و راحت نوشته میشه:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
Promise.all([ fetch('https://api.example.com/user/1'), fetch('https://api.example.com/posts'), fetch('https://api.example.com/comments') ]) .then(responses => Promise.all(responses.map(res => res.json()))) .then(data => { console.log('User:', data[0]); console.log('Posts:', data[1]); console.log('Comments:', data[2]); }) .catch(error => console.error('Error in one of the requests:', error)); |
Promise یک آبجکت هست که یک تسک Asynchronous رو توی جاواساکریپت اجرا می کنه. این آبجکت تو تابع داره resolve و reject که این آبجکت گارانتی میکنه که یکی از این دو قطعا اجرا میشه. بخاطر همین بهش میگن Promise. یعنی گارانتی میکنه که این تسک یا موفق میشه یا نه و خارج از این دو حالت نیست.
با صدا زدن یه Promise شما از دو تابع میتونید استفاده کنید. then و catch اولی وقتی که تسک موفق بشه خروجی رو میگیره و دومی وقتی که
|
1 2 3 4 5 6 7 8 9 10 11 |
const promise = new Promise((resolve, reject) => { console.log('Promise started...'); setTimeout(() => { resolve('Task completed successfully!'); // reject('Oops! Something went wrong.'); // Uncomment to test rejection }, 2000); // Simulates a 2-second delay }); promise .then(result => console.log(result)) // Handles success .catch(error => console.error(error)); // Handles error |
توی کد بالا موارد زیر اتفاق میوفته:
اگر بجای resolve تابع reject رو اجرا کنیم. توی مرحله 4 بجای then تابع catch اجرا میشه.
توی serializer های DRF گاهی لازمه وقتی متد list() اون صدا زده میشه باید قبلش دیتایی که ازش گرفته میشه تغییری بدیم برای این کار از متد to_representaion استفاده میکنیم.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
class LinkAPISerializer(serializers.ModelSerializer): provider_name = serializers.CharField(source='provider.name_fixed', read_only=True) consumer_name = serializers.CharField(source='consumer.name_fixed', read_only=True) interface_name = serializers.CharField(source='interface.name_fixed', read_only=True) interface2_name = serializers.CharField(source='interface2.name_fixed', read_only=True) protocol_name = serializers.CharField(source='protocol.name_fixed', read_only=True) lt_display = serializers.CharField(source='get_lt_display', read_only=True) class Meta: model = Link fields = [ 'id', 'provider', 'provider_name', 'consumer', 'consumer_name', 'interface', 'interface_name', 'interface2', 'interface2_name', 'protocol', 'protocol_name', 'lt', 'lt_display', 'description', 'api', 'frequency', 'ProviderVerified', 'ConsumerVerified', 'ESBVerified', 'api_gateway', 'active' ] def to_representation(self, instance): data = super().to_representation(instance) if data.get('description'): data['description'] = data['description'].strip('\"') return data |
کد زیر یک باگ جالب داره.
|
1 2 3 4 5 6 7 8 |
def clean(self): cleaned_data = super().clean() if cleaned_data.get("branch").name != 'ETC' and cleaned_data.get("office") and cleaned_data.get("branch"): if cleaned_data.get("office").branch != cleaned_data.get("branch"): raise ValidationError("این اداره به اداره کل انتخاب شده مرتبط نیست") return cleaned_data |
در صورتی که branch انتخاب نشده باشه cleaned_data.get(“branch”).name این اکسپشن میده. برای اصلاحش باید یه تغییر ساده بدیم
|
1 2 3 4 5 6 7 8 |
def clean(self): cleaned_data = super().clean() if cleaned_data.get("branch").name != 'ETC' and cleaned_data.get("office") and cleaned_data.get("branch"): if cleaned_data.get("office").branch != cleaned_data.get("branch"): raise ValidationError("این اداره به اداره کل انتخاب شده مرتبط نیست") return cleaned_data |