Githawk: 북마크 재설정(다시)

새로운 매개변수를 추가했기 때문만은 아닙니다. NSMutableOrderedSet 를 사용하도록 상점을 변경했기 때문에 재설정이 발생했습니다.

이것은 DB/마이그레이션을 처리하는 것과 동일한 문제를 제공합니다. 🤦‍♂️

_{GitHawk 와 함께}

Codable이 구조 변경을 처리할 수 없습니다. 따라서 새 속성을 추가하면 역직렬화에 실패합니까?

이 경우 NSCoding 돌아갈 수도 있습니다.

_{GitHawk 와 함께}

정확히, 업그레이드하면 콘솔에서 이 개체가 무엇인지 모르고 실패(따라서 재설정)한다는 오류가 많이 발생합니다.

NSCoding 가 그것을 더 잘 처리한다면 예, 바꿀 가치가 있을 것입니다 😞

NSCoding을 사용하면 모든 권한이 있고 새 값을 선택 사항으로 만들거나 initWithCoding에서 기본값을 제공합니다.

1.12 이전에 이것을 변경해야 합니다.

_{GitHawk 와 함께}

따라서 위에서 제안한 대로 Codable로 그렇게 할 수 있습니다. 하지만 문제는 사용할 수 있고 버그가 없는 기본값이 없다는 것입니다. 내 말은 당신이 "최소한의 경우"라고 주장할 수 있다고 확신하지만 실제로 우리는 요청을 수행하고 새로운 정보로 북마크를 업데이트할 수 있는 마이그레이션 시스템이 필요합니다 🤔

@Sherlouk Spark의 "데이터베이스 업그레이드" 스플래시가

_{GitHawk 와 함께}

그런 의미에서 우리는 이미 버그가 있습니다. repo가 ​​기본 브랜치를 변경하면 어떻게 됩니까?

항목을 방문할 때 항목을 새로 고치는 시스템이 필요한 것처럼 들립니다.

_{GitHawk 와 함께}

책갈피의 의미에서 매우 사실입니다. Issues/Search/etc는 모두 저장소의 최신 참조이므로 해당 정보가 정확합니다.

책갈피 및 최근 검색에는 입력하기 전에 다른 정보를 가져오기 위해 소유자/이름에서 저장소를 로드하는 방법이 필요합니다.

우리가 그렇게 했다면 이슈에 대한 리포지토리와 레이블에 별 수를 표시할 수 있었습니다. 간단하게 유지하고 사물을 입력할 때만 새로 고칠 수 있습니다(일부 동기화 서비스와 비교).

참고로 단일 gql 요청에서 여러 저장소를 쿼리할 수 없습니까? 이름으로 4개의 리포지토리에 대한 하나의 요청과 같습니까?

_{GitHawk 와 함께}

제가 알기로는 1:1로 생각하시면 됩니다. 별, 레이블, 커밋 정보 🤔🤔

_{GitHawk 와 함께}

여기서 무엇을 할까? 이번 주에 1.12를 제출하고 싶습니다. 나는 이 ATM에 대해 크게 걱정하지 않으며 마이그레이션 계획에 대해 생각해야 합니다.

장기적으로 새로 고침 메커니즘이 필요한 것처럼 들리지만 추가하기가 너무 어렵지는 않을 것입니다.

식별자를 기반으로 O(1) 조회를 수행하고 개체를 업데이트할 수 있도록 책갈피를 약간 리팩토링해야 합니까?

나는 개인적으로 이것에 대한 계획 없이 책갈피를 출시하는 것에 대해 꽤 우려하고 있습니다. 마치 우리가 그것을 처리하지 않으면 사용자 책갈피를 계속 지우려고 할 것이기 때문입니다!

_{GitHawk 와 함께}

우리는 책갈피를 지우는 버전을 결코 발송하지 않을 것입니다. 나는 그것을 받아들이지 않을 것입니다. 책갈피를 파괴하는 모든 변경 사항에는 수동이더라도 마이그레이션이 포함되어야 합니다.

_{GitHawk 와 함께}

우리가 지금 통제하고 있다고 생각하기 때문에 이것을 닫습니다. 모든 새 릴리스에 대해 이것을 확인하거나 자동화할 방법을 찾아야 합니다.