Githawk: Signets Réinitialiser (à nouveau)

Pas seulement parce que nous avons ajouté un nouveau paramètre. La réinitialisation s'est produite parce que j'ai changé le magasin pour utiliser NSMutableOrderedSet .

Cela pose les mêmes problèmes de gestion des DB/migrations. 🤦‍♂️

_{Envoyé avec GitHawk}

Attendez que codable ne gère pas les changements de structure ? Donc, si nous ajoutons une nouvelle propriété, la désérialisation échouera ?

Si c'est le cas, autant revenir à NSCoding .

_{Envoyé avec GitHawk}

Exactement, si vous mettez à niveau, vous obtiendrez juste un tas d'erreurs dans la console disant qu'elle ne sait pas ce qu'est cet objet et échouera (donc la réinitialisation)

Si NSCoding gère mieux, alors ça vaut peut-être la peine de changer

Oui, avec NSCoding, vous avez le contrôle total et vous n'avez qu'à rendre les nouvelles valeurs facultatives ou à fournir une valeur par défaut dans initWithCoding.

Nous devrions changer cela avant 1.12

_{Envoyé avec GitHawk}

Il est donc possible de le faire avec Codable, comme je l'ai suggéré ci-dessus - mais le problème est qu'il n'y a pas de valeur par défaut que vous pouvez utiliser et ne pas avoir de bogues. Je veux dire, oui, bien sûr, vous pouvez discuter d'un "cas marginal", mais nous avons vraiment besoin d'un système de migration capable de faire une demande et de mettre à jour les signets avec de nouvelles informations 🤔

@Sherlouk, quelque chose comme le splash de "mise à niveau de la base de données" de Spark me vient à l'esprit

_{Envoyé avec GitHawk}

En ce sens, nous avons déjà des bugs. Que se passe-t-il lorsqu'un repo modifie sa branche par défaut ?

Il semble plutôt que nous ayons besoin d'un système pour actualiser les éléments lorsque vous les visitez.

_{Envoyé avec GitHawk}

Dans le sens des signets, très vrai. Les problèmes/recherche/etc sont tous des références à jour du référentiel afin que leurs informations soient correctes.

Les signets et les recherches récentes ont besoin d'un moyen de charger un référentiel à partir du seul propriétaire/nom pour récupérer les autres informations avant d'entrer

Si nous faisions cela, nous pourrions commencer à afficher le nombre d'étoiles sur les dépôts et les étiquettes sur les problèmes. Pourrait rester simple et ne rafraîchir que lorsque vous entrez dans la chose (par rapport à un service de synchronisation).

Remarque : vous ne pouvez pas interroger plusieurs dépôts dans une seule requête gql, n'est-ce pas ? Alors comme une demande de 4 repos par nom ?

_{Envoyé avec GitHawk}

Pas pour autant que je sache, je pense que c'est 1:1. Étoiles, labels, informations sur les commits 🤔🤔

_{Envoyé avec GitHawk}

Des idées sur ce qu'il faut faire ici ? Souhaitez-vous soumettre 1.12 cette semaine. Je ne suis pas très inquiet pour ce guichet automatique, j'aurai juste besoin de réfléchir à un plan de migration.

On dirait qu'à long terme, nous avons juste besoin d'un mécanisme de rafraîchissement, mais ce ne sera pas trop difficile à ajouter.

Peut-être avons-nous juste besoin de refactoriser un peu les signets pour pouvoir effectuer des recherches O (1) basées sur un identifiant et mettre à jour les objets ?

Personnellement, je suis assez inquiet de publier des signets sans plan pour cela, comme si nous ne le gérons pas, le combat allait continuer à effacer les signets des utilisateurs !

_{Envoyé avec GitHawk}

Nous n'enverrions jamais une version effaçant les signets, je ne l'accepterai pas. Toute modification qui détruirait les signets doit inclure les migrations, même manuelles.

_{Envoyé avec GitHawk}

Clôturer ceci car je pense que nous avons cela sous contrôle en ce moment. Devrait certainement vérifier cela pour chaque nouvelle version - ou trouver un moyen d'automatiser cela.