Engineering Notes

#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 Djangoda fayllarni to'g'ridan-to'g'ri DBda saqlash mumkinmi? Buning qanday kamchiliklari bor? *qisqartirildi

#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 Can anybody explain in simple words to me What does INCLUDE does in CREATE INDEX?

#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 #pycache Assalomu alaykum, _pycache_ fayllar nega kerak, vazifasi nima?

#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

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

Nega user=user ni get dan tashqarida yozildi?

Manetta "kotta bollani" o'yini boshlanayapti. Kuzatamiz. P.S. O'zbekiston ham CIS davlatlariga kiradi.

[Meme] No Title needed... https://redd.it/swtznj 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

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

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

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().

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

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/

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

#yaxshi_savol Serverga kelayotgan requestlarni bitta web application instance ko'tara olmay qolganda load balancingga ehtiyoj tug'iladi. Oddiy tushuntirganda, hamma requestni bitta instancega yuborish o'rniga, bir qancha instancelar ishga tushirib, requestlarni ularning orasida taqsimlab berish. Load balancingning ham turlari bor. Backend developmentda eng keng tarqalganlari layer 7 va layer 4 load balancing. Ya'ni, OSI modelining yettinchi (application) va to'rtinchi (transport) qavatida turib taqsimlash. Savol: L7 va L4 load balancerlarning har birining qanday yaxshi va yomon taraflari bor? Javoblarni iloji boricha batafsil yozib, discussionda qoldirishingiz mumkin.

#yaxshi_savol PostgreSQL bilan ishlaganda, deylik siz bir ma'lumotni UPDATE yoki DELETE qildingiz. Lekin shu vaqtning o'zida eski qiymat ham tabledan o'chib ketmaydi. Masalan, sizda id INT, name VARCHAR columnlaridan iborat persons table bor. Deylik, unda 1 ta row: (1, 'John') bor. Keyin siz uni yangiladingiz: UPDATE persons SET name = 'Doe' WHERE id = 1; Yoki o'chirib yubordingiz: DELETE FROM persons WHERE id = 1; Lekin ikki holda ham eski qiymat, ya'ni (1, 'John') xotiradan o'sha vaqtning o'zida o'chib ketmaydi. Savol: Eski qiymatlarni xotirada vaqtinchalik saqlab qolish nima uchun kerak va buning qanday negativ natijalari bo'lishi mumkin? Javoblarni iloji boricha batafsil yozib, discussionda qoldirishingiz mumkin.

#yaxshi_savol Avval web development yaxlit bitta soha edi. Keyin ikki asosiy qism: frontend va backendga ajraldi. Qizig'i, aslida bu qismlar abstrakt emas, nisbiy. Biz biladigan frontend va backend butun boshli web applicationga nisbatan olingan. Web applicationning bir qismi uchun ham frontend va backend qismlari bor. Masalan, backend web serverning frontend qismi bu API. Endi savol. Biz biladigan web backendning o'zi uchun ham backend qismi bor. Bu nimaligini ko'pchilik biladi. Qizig'i, o'sha qismning ham frontend va backend qismlari bor. Siz kommentlarda shu backend, ya'ni web backendning backend qismining backend qismi nimaligini ayting. Iloji bo'lsa, batafsilroq javob qoldiring. U nima, nega kerak, qanday ishlaydi, qanday turlari bor va hokazo. P.S. Tanishlarga ham share qilsangiz xursand bo'lardim.