Githawk: Setel Ulang Bookmark (lagi)
Karena kami menggunakan bentuk kode yang sangat ketat, Bookmark akan diatur ulang setiap kali kami memodifikasi struct.
Bukti A: https://github.com/rnystrom/GitHawk/blob/10e7b67f581ee05403fe44e4e9a444bafda0f05f/Classes/Bookmark/BookmarkModel.swift#L28 baru saja merusaknya lagi (maaf!)
Apakah ada cara kita dapat mengubah ini menjadi sedikit lebih fleksibel, jika tidak, setelah ini ditayangkan, kita akan memiliki masalah di mana pada dasarnya kita tidak dapat mengubah fungsinya tanpa merusak cache!
Saya berpikir, mengingat saya belum melakukan banyak hal dengan codable jadi mungkin tidak mungkin, tetapi jika kita menulis init kita sendiri dari codable maka nilai baru dapat diperlakukan sebagai opsional dan nilai default? (Ini juga akan menyebabkan masalah karena, misalnya seperti di atas - cabang default = salah = tampilan kode akan salah jadi )
Yh tidak yakin @rizwankce ada ide?
Sherlouk
Semua 14 komentar
Bukan hanya karena kami menambahkan parameter baru. Reset terjadi karena saya mengubah toko untuk menggunakan NSMutableOrderedSet .
Ini memberikan masalah yang sama dalam menangani DB/migrasi. ️
Dikirim dengan GitHawk
rizwankce
pada 5 Nov 2017
Tunggu bisakah codeable tidak menangani perubahan struktur? Jadi jika kita menambahkan properti baru, itu akan gagal untuk deserialize?
Jika itu masalahnya, sebaiknya kita kembali ke NSCoding .
Dikirim dengan GitHawk
rnystrom
pada 5 Nov 2017
Tepat, jika Anda memutakhirkan, Anda hanya akan mendapatkan banyak kesalahan di konsol yang mengatakan tidak tahu apa objek ini dan gagal (sehingga mengatur ulang)
Jika NSCoding menanganinya dengan lebih baik maka ya mungkin sepadan dengan perubahannya
Sherlouk
pada 5 Nov 2017
Ya dengan NSCoding Anda memiliki kontrol penuh dan hanya membuat nilai baru opsional, atau memberikan default di initWithCoding.
Kita harus mengubah ini sebelum 1.12
Dikirim dengan GitHawk
rnystrom
pada 5 Nov 2017
Jadi dimungkinkan untuk melakukannya dengan Codable, seperti yang saya sarankan di atas -- tetapi masalahnya adalah tidak ada nilai default yang dapat Anda gunakan dan tidak memiliki bug. Maksud saya ya, tentu Anda dapat berdebat tentang "kasus tepi" tetapi sebenarnya kami membutuhkan sistem migrasi yang dapat melakukan permintaan dan memperbarui bookmark dengan informasi baru
Sherlouk
pada 5 Nov 2017
@Sherlouk sesuatu seperti percikan "peningkatan basis data" Spark muncul di pikiran
Dikirim dengan GitHawk
Iron-Ham
pada 5 Nov 2017
Dalam pengertian itu kita sudah memiliki bug. Apa yang terjadi ketika repo mengubah cabang defaultnya?
Sepertinya kami membutuhkan sistem untuk menyegarkan item saat Anda mengunjunginya.
Dikirim dengan GitHawk
rnystrom
pada 5 Nov 2017
Dalam arti bookmark, sangat benar. Issues/Search/etc semuanya merupakan referensi terbaru dari repositori sehingga informasinya akan benar.
Penanda dan pencarian terbaru memerlukan cara untuk memuat repositori hanya dari pemilik/nama untuk mengambil informasi lain sebelum masuk
Sherlouk
pada 5 Nov 2017
Heck jika kami melakukannya, kami dapat mulai menunjukkan jumlah bintang pada repo dan label pada masalah. Dapat membuatnya tetap sederhana dan hanya menyegarkan saat Anda memasukkannya (vs beberapa layanan sinkronisasi).
Catatan tambahan, Anda tidak dapat meminta beberapa repo dalam satu permintaan gql, bukan? Jadi seperti satu permintaan untuk 4 repo dengan nama?
Dikirim dengan GitHawk
rnystrom
pada 5 Nov 2017
Tidak sejauh yang saya ketahui, anggap saja 1:1. Bintang, label, info komit
Dikirim dengan GitHawk
Sherlouk
pada 5 Nov 2017
Pikiran tentang apa yang harus dilakukan di sini? Ingin mengirimkan 1,12 minggu ini. Saya tidak terlalu khawatir tentang atm ini, hanya perlu memikirkan rencana migrasi.
Kedengarannya seperti jangka panjang kita hanya perlu mekanisme penyegaran, tapi itu tidak akan terlalu sulit untuk ditambahkan.
Mungkin kita hanya perlu sedikit memfaktorkan ulang bookmark sehingga kita dapat melakukan pencarian O(1) berdasarkan pengenal dan memperbarui objek?
rnystrom
pada 6 Nov 2017
Saya pribadi cukup khawatir untuk merilis bookmark tanpa rencana untuk ini seolah-olah kami tidak menanganinya, pertarungan akan terus menghapus bookmark pengguna!
Dikirim dengan GitHawk
Sherlouk
pada 6 Nov 2017
Kami tidak akan pernah mengirimkan versi menghapus bookmark, saya tidak akan menerimanya. Setiap perubahan yang akan menghancurkan bookmark harus menyertakan migrasi, meskipun manual.
Dikirim dengan GitHawk
rnystrom
pada 6 Nov 2017
Menutup ini karena saya pikir kami memiliki ini di bawah kendali sekarang. Pasti harus memeriksa ini untuk setiap rilis baru - atau temukan cara untuk mengotomatiskannya.
BasThomas
pada 3 Des 2017
Masalah terkait
BasThomas
·
3Komentar
BasThomas
·
3Komentar
Iron-Ham
·
3Komentar
rnystrom
·
3Komentar
rnystrom
·
3Komentar
Komentar yang paling membantu
Kami tidak akan pernah mengirimkan versi menghapus bookmark, saya tidak akan menerimanya. Setiap perubahan yang akan menghancurkan bookmark harus menyertakan migrasi, meskipun manual.
Dikirim dengan GitHawk