Githawk: إعادة تعيين الإشارات المرجعية (مرة أخرى)

ليس فقط لأننا أضفنا معلمة جديدة. حدثت إعادة التعيين لأنني قمت بتغيير المتجر لاستخدام NSMutableOrderedSet .

هذا يعطي نفس مشاكل التعامل مع DB / التهجيرات. 🤦‍♂️

_{مرسلة مع GitHawk}

انتظر هل لا يمكن للشفرة أن تتعامل مع تغييرات الهيكل؟ لذا إذا أضفنا خاصية جديدة فسوف تفشل في إلغاء التسلسل؟

إذا كان هذا هو الحال ، فقد نعود أيضًا إلى NSCoding .

_{مرسلة مع GitHawk}

بالضبط ، إذا قمت بالترقية ، فستحصل فقط على مجموعة من الأخطاء في وحدة التحكم تقول إنها لا تعرف ما هو الجحيم هذا الكائن وتفشل (وبالتالي إعادة التعيين)

إذا كان NSCoding يعالج الأمر بشكل أفضل ، فقد يكون الأمر يستحق التغيير 😞

Ya مع NSCoding ، لديك تحكم كامل وتجعل القيم الجديدة اختيارية ، أو توفر قيمة افتراضية في initWithCoding.

يجب أن نغير هذا قبل 1.12

_{مرسلة مع GitHawk}

لذلك من الممكن القيام بذلك باستخدام Codable ، كما اقترحت أعلاه - ولكن المشكلة أنه لا توجد قيمة افتراضية يمكنك استخدامها وليس بها أخطاء. أقصد بالتأكيد أنه يمكنك مناقشة "حالة الحافة" ولكننا نحتاج حقًا إلى نظام ترحيل يمكنه إجراء طلب وتحديث الإشارات المرجعية بمعلومات جديدة 🤔

Sherlouk شيء مثل سبارك "ترقية قاعدة البيانات" يتبادر إلى الذهن

_{مرسلة مع GitHawk}

بهذا المعنى لدينا بالفعل أخطاء. ماذا يحدث عندما يغير الريبو فرعه الافتراضي؟

يبدو أننا بحاجة إلى نظام لتحديث العناصر عند زيارتها.

_{مرسلة مع GitHawk}

بمعنى الإشارات ، صحيح جدا. القضايا / البحث / إلخ كلها مراجع محدثة للمستودع لذا ستكون معلوماتهم صحيحة.

تحتاج الإشارات المرجعية وعمليات البحث الأخيرة إلى طريقة لتحميل مستودع من المالك / الاسم فقط لجلب المعلومات الأخرى قبل الدخول

هيك إذا فعلنا ذلك ، فيمكننا البدء في عرض عدد النجوم على المستودعات والتسميات على المشكلات. يمكن أن يبقي الأمر بسيطًا ويتم التحديث فقط عند إدخال الشيء (مقابل بعض خدمات المزامنة).

ملاحظة جانبية ، لا يمكنك الاستعلام عن عدة مستودعات في طلب gql واحد ، أليس كذلك؟ إذن مثل طلب واحد لـ 4 مستودعات بالاسم؟

_{مرسلة مع GitHawk}

ليس بقدر ما أدرك ، أعتقد أنه 1: 1. النجوم ، والتسميات ، وتنفيذ المعلومات 🤔🤔

_{مرسلة مع GitHawk}

أفكار حول ما يجب القيام به هنا؟ أود أن يقدم 1.12 هذا الأسبوع. لست قلقًا للغاية بشأن هذا الصراف الآلي ، سأحتاج فقط إلى التفكير في خطة الهجرة.

يبدو أنه على المدى الطويل ، نحتاج فقط إلى آلية تحديث ، لكن لن يكون من الصعب جدًا إضافة ذلك.

ربما نحتاج فقط إلى إعادة بناء الإشارات المرجعية قليلاً حتى نتمكن من إجراء عمليات بحث O (1) بناءً على المعرف وتحديث الكائنات؟

أنا شخصياً مهتم للغاية بإصدار إشارات مرجعية بدون خطة لهذا الأمر كما لو أننا لم نتعامل معها ، فسنستمر في مسح إشارات المستخدمين!

_{مرسلة مع GitHawk}

لن نشحن أبدًا إصدارًا يمسح الإشارات المرجعية ، ولن أقبل ذلك. يجب أن تتضمن أي تغييرات من شأنها تدمير الإشارات المرجعية عمليات الترحيل ، حتى لو كانت يدوية.

_{مرسلة مع GitHawk}

إغلاق هذا كما أعتقد أن لدينا هذا تحت السيطرة الآن. يجب عليك بالتأكيد التحقق من ذلك لكل إصدار جديد - أو إيجاد طريقة لأتمتة ذلك.