Githawk: बुकमार्क रीसेट (फिर से)

केवल इसलिए नहीं कि हमने नया पैरामीटर जोड़ा है। रीसेट खुश है क्योंकि मैंने स्टोर को NSMutableOrderedSet का उपयोग करने के लिए बदल दिया है।

यह डीबी/माइग्रेशन को संभालने की समान समस्याएं दे रहा है। ‍♂️

_{GitHawk . के साथ भेजा गया}

प्रतीक्षा करें कोडेबल संरचना परिवर्तनों को संभाल नहीं सकता है? तो अगर हम एक नई संपत्ति जोड़ते हैं तो यह deserialize करने में असफल हो जाएगा?

अगर ऐसा है तो हम NSCoding वापस आ सकते हैं।

_{GitHawk . के साथ भेजा गया}

वास्तव में, यदि आप अपग्रेड करते हैं तो आपको कंसोल में त्रुटियों का एक गुच्छा मिलेगा, यह कहते हुए कि यह नहीं जानता कि यह वस्तु क्या है और विफल (इस प्रकार रीसेट करना)

अगर NSCoding इसे बेहतर तरीके से संभालता है तो हाँ बदलाव के लायक हो सकता है

हां एनएससीओडिंग के साथ आपका पूर्ण नियंत्रण है और केवल नए मान वैकल्पिक बनाएं, या initWithCoding में डिफ़ॉल्ट प्रदान करें।

हमें इसे 1.12 . से पहले बदलना चाहिए

_{GitHawk . के साथ भेजा गया}

तो कोडेबल के साथ ऐसा करना संभव है, जैसा कि मैंने ऊपर सुझाव दिया है - लेकिन मुद्दा यह है कि कोई डिफ़ॉल्ट मान नहीं है जिसका आप उपयोग कर सकते हैं और बग नहीं हैं। मेरा मतलब है कि हाँ यकीन है कि आप "एज केस" पर बहस कर सकते हैं लेकिन वास्तव में हमें एक माइग्रेशन सिस्टम की आवश्यकता है जो एक अनुरोध कर सके और नई जानकारी के साथ बुकमार्क अपडेट कर सके

@ शेरलोक स्पार्क के "अपग्रेडिंग डेटाबेस" स्पलैश जैसा कुछ दिमाग में आता है

_{GitHawk . के साथ भेजा गया}

उस अर्थ में हमारे पास पहले से ही बग हैं। क्या होता है जब कोई रेपो अपनी डिफ़ॉल्ट शाखा बदलता है?

ऐसा लगता है कि जब आप आइटम पर जाते हैं तो हमें उन्हें रीफ्रेश करने के लिए सिस्टम की आवश्यकता होती है।

_{GitHawk . के साथ भेजा गया}

बुकमार्क के अर्थ में, बिल्कुल सही। मुद्दे/खोज/आदि सभी रिपोजिटरी के अद्यतन संदर्भ हैं इसलिए उनकी जानकारी सही होगी।

बुकमार्क और हाल की खोजों को दर्ज करने से पहले अन्य जानकारी प्राप्त करने के लिए सिर्फ मालिक/नाम से एक भंडार लोड करने का एक तरीका चाहिए

बिल्ली अगर हमने ऐसा किया तो हम मुद्दों पर रेपो और लेबल पर स्टार गिनती दिखाना शुरू कर सकते हैं। इसे सरल रख सकते हैं और जब आप चीज़ दर्ज करते हैं तो केवल रीफ्रेश करें (बनाम कुछ सिंक सेवा)।

साइड नोट, आप एक ही जीक्यूएल अनुरोध में एकाधिक रेपो से पूछताछ नहीं कर सकते हैं? तो नाम से 4 रेपो के लिए एक अनुरोध की तरह?

_{GitHawk . के साथ भेजा गया}

जहाँ तक मेरी जानकारी है, यह 1:1 लगता है। सितारे, लेबल, प्रतिबद्ध जानकारी

_{GitHawk . के साथ भेजा गया}

यहाँ क्या करना है पर विचार? इस सप्ताह 1.12 प्रस्तुत करना चाहेंगे। मैं इस एटीएम को लेकर बहुत चिंतित नहीं हूं, बस एक माइग्रेशन प्लान के बारे में सोचने की जरूरत है।

लंबी अवधि की तरह लगता है कि हमें केवल एक ताज़ा तंत्र की आवश्यकता है, लेकिन इसे जोड़ना बहुत मुश्किल नहीं होगा।

हो सकता है कि हमें बस बुकमार्क्स को थोड़ा रिफलेक्टर करने की आवश्यकता हो ताकि हम पहचानकर्ता के आधार पर ओ (1) लुकअप कर सकें और वस्तुओं को अपडेट कर सकें?

मैं व्यक्तिगत रूप से इसके लिए योजना के बिना बुकमार्क जारी करने के लिए बहुत चिंतित हूं जैसे कि हम इसे संभाल नहीं पाते हैं लड़ाई उपयोगकर्ताओं के बुकमार्क को साफ़ करने के लिए जारी रहेगी!

_{GitHawk . के साथ भेजा गया}

हम कभी भी बुकमार्क को मिटाते हुए संस्करण नहीं भेजेंगे, मैं इसे स्वीकार नहीं करूंगा। बुकमार्क को नष्ट करने वाले किसी भी परिवर्तन में माइग्रेशन शामिल होना चाहिए, भले ही वह मैनुअल ही क्यों न हो।

_{GitHawk . के साथ भेजा गया}

इसे बंद करना क्योंकि मुझे लगता है कि अभी हमारे पास यह नियंत्रण में है। हर नई रिलीज के लिए इसे निश्चित रूप से जांचना चाहिए - या इसे स्वचालित करने का कोई तरीका ढूंढना चाहिए।