Maqola yozish uchun yaxshi mavzular o'ylab yuribman, lekin vaqt ajratish muammo bo'layapti.
Inshaalloh, yaqin kunlarda database bo'yicha yangi maqola chiqadi.

Yaxshi maqola ekan, vaqt topib o'qib chiqsangiz, eng kamida hali Pythondagi ko'p narsadan xabaringiz yo'qligini tushunasiz ))

https://realpython.com/python-memory-management/

#question
What are prefetch_related() and select_related() in django querysets and how they work?

Well, most of the time you wanna retrieve data from more than one table. In that case, you need an efficient way to play with more than just one model.

Let's say you have a Book model that has a ForeignKey relationship to Author model. You wanna get information about all books and their authors in a single view.

Let's say you have n books. You'll get all Book objects with a single DB query via Book.objects.all() queryset.
But each time you ask for the author of a book, django makes another DB query to retrieve information about the author of this book. In total, django performs n+1 queries: 1 query to get all the books and n queries to get authors of n books. This is what they call n+1 problem.

This is where prefetch_related() and select_related() come into the picture.
They have different purposes and they work differently.

1. select_related() simply makes a SQL JOIN for each selected relationship in a model. In simple words, you'll get data from multiple tables within a single query. For the example above, it joins the author table to the book table with book.author_id = author.id condition.
Instead of n+1 queries, you'll make 1 complex query to retrieve all the necessary data.
select_related() is limited to a single relationship level. This means, it can be used for first-level one-to-one and many-to-one relationships. If you have this kinda relationship:
Book -> Author -> User,
You cannot get data in User model from Book, because they don't have a direct relationship between them.

2. prefetch_related() is designed for more than 1 level relationship (like Author, Book, User example). Since it's not a direct relationship, you cannot make a SQL JOIN here. What prefetch_related() does is simply doing a separate query for each relationship, but all in a single batch.
You might be wondering then how it could be different from the usual way, if still it makes a separate query for each relationship. For example, if you loop through all the books and access to its author, django makes a query at the moment where you ask for it, which kills the performance. On the other hand, a queryset using prefetch_related fetches all the necessary data when you ask for all the books and author will be already there when you ask for them.
Since many-to-many relationship is technically combination of 2 foreignkeys, you cannot use select_related() with them. Here what you need is prefetch_related().

Mana haqiqiy daraja o'rtoqlar.
Dasturlashni kasb emas, san'at deb qabul qiladiganlarni ko'rsam maza qilaman ))
https://youtu.be/k13LpTPdxt4?t=767

Life of a DNS query
https://redd.it/scxe9z

by @programmer_humor

Netflixning backend arxitekturasini ko'rgandim, juda aqlli ishlab chiqilgan.
Hozir esa frontend qismini ko'rib yana bir marta qoyil qoldim.
Inshaalloh, bir kun kelib Netflixda ishlashni niyat qildim.

Ko'rib chiqishni tavsiya qilaman:
https://youtu.be/MxFt3YsjyQg

[Meme] No Title needed...
https://redd.it/swtznj

by @programmer_humor

Manetta "kotta bollani" o'yini boshlanayapti. Kuzatamiz.

P.S. O'zbekiston ham CIS davlatlariga kiradi.

#savol

database_sync_to_async(Profile.objects.get)(user=user)

Nega user=user ni get dan tashqarida yozildi?

#javob

Sababi, bu argumentni get() methodining ichiga yozsangiz get() methodi ishga tushadi va database_sync_to_async() bu funksiyadan qaytgan return valuega qarab ishlaydi.

Argumentlarni get() methodidan tashqarida bersangiz esa database_sync_to_async() funksiyasi mana shu methodni parameter sidatida oladi(sababi, u hali ishlamadi, funksiya holida turibdi) va async functionga o'tkazib beradi. Hosil bo'lgan yangi funksiyaga esa parameterlar beriladi.

Bu xuddi decoratorga o'xshash, aniqrog'i, decorator.

#savol #pycache
Assalomu alaykum, _pycache_ fayllar nega kerak, vazifasi nima?

#javob

Python interpreted language bo'lsa-da, unda ham compilingga o'xshash jarayon bo'ladi.
Avval to'liq source code bytecode deb ataluvchi instruksiyalar ketma-ketligiga o'tkazib chiqiladi.
Bu instruksiyalarni esa Python virtual machine (biz bilgan python interpreter) olib, uni execute qiladi.

Odatda, bytecode __pycache__ folderining ichidagi .pyc fayllarga yozib qo'yiladi. Xuddi shu dastur keyingi safar run qilinganda esa Python kodni yana bytecodega o'tkazib chiqmasdan, tayyor turgan bytecodeni ishlatadi. Natijada tezlik oshadi. Har safar fayllardan o'zgarish bo'lganda ular yana qaytadan bytecodega o'tkaziladi. Lekin bu ba'zida sodir bo'lmasligi mumkin va natijada kodni o'zgartirsangiz ham, eski kod run bo'laveradi.

#savol
Can anybody explain in simple words to me
What does INCLUDE does in CREATE INDEX?

#javob

It includes non-index column values to the actual index (b-tree).

Let's say you have a table named "users" with id, name and a bunch of other columns.
If you include name column in the index on id field:
CREATE INDEX
idx_user_id_include_name
ON users(id)
INCLUDE name;

Each time you query that uses this index and only asks for the columns on the index:

SELECT id, name 
FROM users
WHERE id = 1;

PostgreSQL doesn't necessarily go to the actual table after finding the required row, since it can find both id and name field on the index. This is called index-only scan.

If you query some other columns (let's say age), PostgreSQL first finds the required row id from the index and go to that row on the table to get age value, since it's not presented on the index. Searching on the index and fetching from the actual table. This is called index scan.

#savol
Djangoda fayllarni to'g'ridan-to'g'ri DBda saqlash mumkinmi?
Buning qanday kamchiliklari bor?
*qisqartirildi

#javob

Django default holatda fileni DBga yuklamaydi. Bu uchun alohida file system ishlatadi. Ya'ni mediafilelar serverda(yoki cloudda) ko'rsatilgan biror directoryda saqlanadi va DBda faqat o'sha files olib boradigan path saqlanadi. Client fileni so'raganda esa DB fileni bermasdan, uning turgan joyini ko'rsatib, "faylni o'sha yerdan topasan" deydi. File aytilgan joydan topilmasa, DB aybni bo'yniga olmaydi ))

Siz so'rayotgan narsa esa BLOB deyiladi, ya'ni katta fileni to'g'ridan to'g'ri DBda saqlash(aslini olganda, bunda ham file tableda saqlanmaydi).
BinaryField orqali djangoda ham BLOB sifatida ishlatishingiz mumkin.

BLOBning men biladigan kamchiliklari:
— Nisbatan sekin. File "cherez baza" uzatiladi.
— Katta filelarni backup qilish qiyin.
— Cache qilish qiyin.

Lekin masalan, softwareni boshqa serverga migrate qilayotganda juda qo'l keladi.

#savol

Shu error nimadan kelib chiqvoti?

psycopg2.InterfaceError: connection already closed