Githawk: Lesezeichen zurücksetzen (erneut)

Nicht nur, weil wir neue Parameter hinzugefügt haben. Das Zurücksetzen geschah, weil ich den Speicher geändert habe, um NSMutableOrderedSet .

Dies führt zu denselben Problemen bei der Handhabung von DB/Migrationen. ️

_{Gesendet mit GitHawk}

Warten Sie, kann codierbar Strukturänderungen nicht verarbeiten? Wenn wir also eine neue Eigenschaft hinzufügen, kann sie nicht deserialisiert werden?

Wenn das der Fall ist, können wir genauso gut auf NSCoding zurückgreifen.

_{Gesendet mit GitHawk}

Genau, wenn Sie ein Upgrade durchführen, erhalten Sie nur eine Reihe von Fehlern in der Konsole, die sagen, dass sie nicht weiß, was zum Teufel dieses Objekt ist, und schlägt fehl (und wird daher zurückgesetzt).

Wenn NSCoding besser damit umgehen kann, dann könnte sich die Änderung lohnen

Ja mit NSCoding haben Sie die volle Kontrolle und machen neue Werte einfach optional oder geben einen Standard in initWithCoding an.

Wir sollten dies vor 1.12 ändern

_{Gesendet mit GitHawk}

Es ist also möglich, dies mit Codable zu tun, wie ich oben vorgeschlagen habe - aber das Problem ist, dass es keinen Standardwert gibt, den Sie verwenden können und keine Fehler haben. Ich meine ja, sicher kann man "Edge Case" argumentieren, aber wir brauchen wirklich ein Migrationssystem, das eine Anfrage stellen und Lesezeichen mit neuen Informationen aktualisieren kann 🤔

@Sherlouk so etwas wie Sparks Splash "Datenbank aktualisieren"

_{Gesendet mit GitHawk}

In diesem Sinne haben wir bereits Fehler. Was passiert, wenn ein Repo seinen Standard-Branch ändert?

Es hört sich eher so an, als ob wir ein System brauchen, um Elemente zu aktualisieren, wenn Sie sie besuchen.

_{Gesendet mit GitHawk}

Im Sinne von Lesezeichen, sehr wahr. Issues/Search/etc sind alle aktuellen Referenzen des Repositorys, sodass ihre Informationen korrekt sind.

Lesezeichen und kürzliche Suchen benötigen eine Möglichkeit, ein Repository nur vom Eigentümer/Namen zu laden, um die anderen Informationen vor der Eingabe abzurufen

Verdammt, wenn wir das täten, könnten wir anfangen, die Anzahl der Sterne auf Repos und Labels auf Issues anzuzeigen. Könnte es einfach halten und nur aktualisieren, wenn Sie das Ding eingeben (im Vergleich zu einem Synchronisierungsdienst).

Randnotiz, Sie können nicht mehrere Repositorys in einer einzigen gql-Anfrage abfragen, oder? Also wie eine Anfrage für 4 Repos namentlich?

_{Gesendet mit GitHawk}

Soweit ich weiß nicht, denke es ist 1:1. Sterne, Labels, Commit-Infos

_{Gesendet mit GitHawk}

Gedanken, was hier zu tun ist? Möchte diese Woche 1.12 einreichen. Ich mache mir keine großen Sorgen um diesen Geldautomaten, muss nur über einen Migrationsplan nachdenken.

Klingt so, als ob wir langfristig nur einen Aktualisierungsmechanismus brauchen, aber das wird nicht allzu schwierig sein, ihn hinzuzufügen.

Vielleicht müssen wir die Lesezeichen nur ein wenig umgestalten, damit wir O(1)-Lookups basierend auf einem Bezeichner durchführen und die Objekte aktualisieren können?

Ich persönlich bin ziemlich besorgt, Lesezeichen ohne einen Plan dafür freizugeben, als ob wir uns nicht darum kümmern würden, die Lesezeichen der Benutzer zu löschen!

_{Gesendet mit GitHawk}

Wir würden niemals eine Version versenden, die Lesezeichen löscht, das werde ich nicht akzeptieren. Alle Änderungen, die Lesezeichen zerstören würden, sollten Migrationen umfassen, auch wenn sie manuell erfolgen.

_{Gesendet mit GitHawk}

Ich schließe dies, da ich denke, dass wir das jetzt im Griff haben. Sollte dies auf jeden Fall bei jeder neuen Version überprüfen - oder einen Weg finden, das zu automatisieren.