Githawk: Marcadores Restablecer (nuevamente)

No solo porque agregamos un nuevo parámetro. El reinicio sucedió porque cambié la tienda para usar NSMutableOrderedSet .

Esto está dando los mismos problemas de manejo de DB / migraciones. 🤦‍♂️

_{Enviado con GitHawk}

Espere, ¿puede codificarse no manejar cambios de estructura? Entonces, si agregamos una nueva propiedad, ¿no se deserializará?

Si ese es el caso, también podríamos volver a NSCoding .

_{Enviado con GitHawk}

Exactamente, si actualiza, obtendrá un montón de errores en la consola diciendo que no sabe qué diablos es este objeto y fallará (reiniciando así)

Si NSCoding maneja mejor, entonces vale la pena el cambio 😞

Ya con NSCoding tiene el control total y simplemente hace que los nuevos valores sean opcionales, o proporcione un valor predeterminado en initWithCoding.

Deberíamos cambiar esto antes de la 1.12

_{Enviado con GitHawk}

Entonces, es posible hacer eso con Codable, como sugerí anteriormente, pero el problema es que no hay un valor predeterminado que pueda usar y que no tenga errores. Quiero decir, sí, seguro que puedes argumentar "casos extremos", pero realmente necesitamos un sistema de migración que pueda realizar una solicitud y actualizar los marcadores con nueva información 🤔

@Sherlouk me viene a la mente algo como el

_{Enviado con GitHawk}

En ese sentido ya tenemos errores. ¿Qué sucede cuando un repositorio cambia su rama predeterminada?

Parece más bien que necesitamos un sistema para actualizar los elementos cuando los visita.

_{Enviado con GitHawk}

En el sentido de marcadores, muy cierto. Los problemas / búsqueda / etc.son todas referencias actualizadas del repositorio, por lo que su información será correcta.

Los marcadores y las búsquedas recientes necesitan una forma de cargar un repositorio solo del propietario / nombre para obtener la otra información antes de ingresar

Diablos, si hiciéramos eso, podríamos comenzar a mostrar el recuento de estrellas en los repositorios y las etiquetas en los problemas. Podría mantenerlo simple y solo actualizar cuando ingrese a la cosa (en comparación con algún servicio de sincronización).

Nota al margen, no puede consultar varios repositorios en una sola solicitud gql, ¿verdad? Entonces, ¿como una solicitud de 4 repositorios por nombre?

_{Enviado con GitHawk}

No que yo sepa, creo que es 1: 1. Estrellas, etiquetas, información de confirmación 🤔🤔

_{Enviado con GitHawk}

¿Pensamientos sobre qué hacer aquí? Me gustaría enviar 1.12 esta semana. No estoy muy preocupado por este cajero automático, solo tendré que pensar en un plan de migración.

Parece que a largo plazo solo necesitamos un mecanismo de actualización, pero no será demasiado difícil de agregar.

¿Quizás solo necesitamos refactorizar un poco los marcadores para poder hacer búsquedas O (1) basadas en un identificador y actualizar los objetos?

Personalmente, estoy bastante preocupado por lanzar marcadores sin un plan para esto, ya que si no lo manejáramos, ¡la lucha continuaría limpiando los marcadores de los usuarios!

_{Enviado con GitHawk}

Nunca enviaremos una versión limpiando marcadores, no lo aceptaré. Cualquier cambio que destruya los marcadores debe incluir migraciones, incluso si son manuales.

_{Enviado con GitHawk}

Cerrando esto porque creo que lo tenemos bajo control en este momento. Definitivamente debería verificar esto para cada nueva versión, o encontrar alguna forma de automatizar eso.