Githawk: Redefinir favoritos (novamente)

Não só porque adicionamos um novo parâmetro. A reinicialização aconteceu porque eu mudei a loja para usar NSMutableOrderedSet .

Isso está dando os mesmos problemas de manipulação de banco de dados / migrações. 🤦‍♂️

_{Enviado com GitHawk}

Espere, o codable não consegue lidar com as mudanças na estrutura? Portanto, se adicionarmos uma nova propriedade, ela não será desserializada?

Se for esse o caso, podemos voltar a NSCoding .

_{Enviado com GitHawk}

Exatamente, se você atualizar, você apenas obterá um monte de erros no console dizendo que ele não sabe o que diabos é esse objeto e falhará (reiniciando assim)

Se NSCoding lida melhor, então sim, pode valer a pena a mudança 😞

Com o NSCoding, você tem controle total e apenas torna os novos valores opcionais ou fornece um padrão em initWithCoding.

Devemos mudar isso antes de 1.12

_{Enviado com GitHawk}

Portanto, é possível fazer isso com Codable, como sugeri acima - mas o problema é que não existe um valor padrão que você pode usar e não há bugs. Quero dizer, claro que você pode argumentar "caso extremo", mas realmente precisamos de um sistema de migração que possa fazer uma solicitação e atualizar os favoritos com novas informações 🤔

@Sherlouk algo como o splash de "atualizando o banco de dados" do Spark vem à mente

_{Enviado com GitHawk}

Nesse sentido, já temos bugs. O que acontece quando um repo altera seu branch padrão?

Parece que precisamos de um sistema para atualizar os itens quando você os visita.

_{Enviado com GitHawk}

No sentido de marcadores, é verdade. Problemas / Pesquisa / etc são todas referências atualizadas do repositório, portanto, suas informações estarão corretas.

Os favoritos e pesquisas recentes precisam de uma maneira de carregar um repositório apenas do proprietário / nome para buscar as outras informações antes de inserir

Se fizéssemos isso, poderíamos começar a mostrar contagem de estrelas em repositórios e rótulos em questões. Pode mantê-lo simples e só atualizar quando você entra na coisa (em vez de algum serviço de sincronização).

Observação: você não pode consultar vários repositórios em uma única solicitação gql, certo? Então, como uma solicitação de 4 repositórios por nome?

_{Enviado com GitHawk}

Não que eu saiba, acho que é 1: 1. Estrelas, rótulos, informações de confirmação 🤔🤔

_{Enviado com GitHawk}

Reflexões sobre o que fazer aqui? Gostaria de enviar 1,12 esta semana. Não estou muito preocupado com esse caixa eletrônico, só preciso pensar em um plano de migração.

Parece que precisamos de um mecanismo de atualização a longo prazo, mas isso não será muito difícil de adicionar.

Talvez precisemos apenas refatorar os favoritos um pouco para que possamos fazer pesquisas O (1) com base em um identificador e atualizar os objetos?

Pessoalmente, estou muito preocupado em lançar favoritos sem um plano para isso, pois se não resolvermos isso continuaríamos a limpar os favoritos dos usuários!

_{Enviado com GitHawk}

Jamais enviaríamos uma versão apagando os favoritos, não vou aceitar isso. Quaisquer alterações que possam destruir os favoritos devem incluir migrações, mesmo que sejam manuais.

_{Enviado com GitHawk}

Fechando isso porque acho que temos tudo sob controle agora. Definitivamente, deve verificar isso para cada novo lançamento - ou encontrar uma maneira de automatizar isso.