नोट: यह Make WP Slack पर हुई बातचीत से अनुकूलित किया गया है (अधिक संदर्भ के लिए लिंक देखें)।
थंबनेल के संबंध में हमारी वर्तमान स्थिति
प्रदाताओं द्वारा थंबनेल एकत्र किए गए और कैटलॉग में thumbnail कॉलम में रखे गए। अब हमारे पास वहां डेटा है, और कॉलम हटाया नहीं गया है। चूंकि यह कॉलम API में भी मौजूद है, इसलिए इसमें मौजूद डेटा (ऑडियो और इमेज दोनों के लिए) वहां भी thumbnail कॉलम में कॉपी हो जाता है। हालांकि, केवल Audio मॉडल ही thumbnail कॉलम का उपयोग करता है; Image मॉडल इसे अनदेखा करता है और प्राथमिक इमेज URL का उपयोग करके छोटे आकार का थंबनेल बनाने का प्रयास करता है। प्रदाता में MediaStore क्लास को इस तरह संशोधित किया गया है कि thumbnail कॉलम में कोई नया थंबनेल URL नहीं जोड़ा जा सके, लेकिन उन्हें meta_data["thumbnail_url"] के अंतर्गत मेटाडेटा में जोड़ा जा सकता है।
हाल ही में हमें ऐसी परिस्थितियों का सामना करना पड़ा है, जहां पूर्ण-आकार वाले इमेज URL से थंबनेल बनाने के हमारे अपने प्रयासों के कारण लगातार टाइमआउट हुए और रिकॉर्ड खोज परिणामों में दिखाई नहीं दे पाए। SMK इसका हालिया उदाहरण है: (1) (2)। इन मामलों में प्रदाता के पहले से गणना किए गए थंबनेल का उपयोग करना लाभदायक हो सकता है। महत्वपूर्ण रूप से, सभी प्रदाता थंबनेल उपलब्ध नहीं कराते हैं और न ही उनसे ऐसा करने की अपेक्षा की जाती है। इसलिए ऐसा लगता है कि हम अपने टेबल की चौड़ाई कम करना चाहेंगे और इस अक्सर खाली रहने वाले कॉलम को हटा सकते हैं।
प्रस्ताव
image के लिए: पहले हम कैटलॉग में मौजूद सभी thumbnail मानों को meta_data["thumbnail_url"] में कॉपी करेंगे। फिर हम नए-टेबल-बिना-कॉलम-स्वैप की प्रक्रिया करेंगे और टेबल से thumbnail कॉलम हटा देंगे। इससे स्थान बचाने और टेबल की चौड़ाई कम करने में मदद मिलेगी। इसके बाद हम image_view मटेरियलाइज़्ड व्यू को अपडेट करेंगे ताकि वह APIAPI API या Application Programming Interface एक सॉफ़्टवेयर मध्यस्थ है, जो प्रोग्रामों को एक-दूसरे के साथ इंटरैक्ट करने और सीमित, स्पष्ट रूप से परिभाषित तरीकों से डेटा साझा करने की अनुमति देता है। के लिए meta_data डिक्शनरी का उपयोग करके एक thumbnail कॉलम भरे। इसका एक उदाहरण Audio व्यू के audio_set_foreign_identifier में है। इससे हम API में thumbnail कॉलम बनाए रख सकेंगे, लेकिन कैटलॉग में स्थान कम कर सकेंगे, क्योंकि API पर इतने बड़े आकार का माइग्रेशनमाइग्रेशन किसी वेबसाइट के कोड, डेटाबेस और मीडिया फ़ाइलों को एक सर्वर से दूसरे सर्वर पर ले जाना। आमतौर पर होस्टिंग कंपनियां बदलते समय किया जाता है। इस समय संभवतः अव्यावहारिक होगा। इसके बाद हम दोनों छोरों के लॉजिक में दो बदलाव करेंगे:
ImageStoreमेंthumbnail_urlहैंडलिंग लॉजिक जोड़ें, जो उस मान को स्वचालित रूप सेmeta_dataडिक्शनरी में रखेगा- API में Image मॉडल के लॉजिक को बदलें ताकि छोटे आकार की इमेज बनाते समय वह पहले
image.thumbnail(जिसे डेटा रिफ्रेश के दौरानmeta_data["thumbnail_url"]से कॉपी किया गया है) का उपयोग करने का प्रयास करे, और फिरimage.urlका प्रयास करे
हम संभवतः Audio के लिए भी ऐसा कर सकते हैं; ऐसा लगता है कि लगभग आधे रिकॉर्ड में थंबनेल नहीं हैं:
deploy@localhost:openledger> select count(*) from audio where thumbnail is null;
+--------+
| count |
|--------|
| 427124 |
+--------+
SELECT 1
Time: 4.354s (4 seconds), executed in: 4.328s (4 seconds)
deploy@localhost:openledger> select count(*) from audio;
+--------+
| count |
|--------|
| 949384 |
+--------+
SELECT 1
Time: 3.899s (3 seconds), executed in: 3.887s (3 seconds)
आप सभी इस दृष्टिकोण के बारे में क्या सोचते हैं? मेरा मानना है कि हमारे DB टेबल की चौड़ाई कम करने का कोई भी प्रयास महत्वपूर्ण है, क्योंकि इससे आगे चलकर माइग्रेशन और डेटा प्रबंधन आसान हो जाएगा।