La refactorización con EFCore ya está aquí
Esta página fue traducida por PageTurner AI (beta). No está respaldada oficialmente por el proyecto. ¿Encontraste un error? Reportar problema →
EFCore ha llegado a las builds inestables, y esto tendrá consecuencias.
Finalmente hemos alcanzado nuestro primer hito en la limpieza del código heredado de acceso a bases de datos. Esto significa que todos los constructores SQL que apuntaban directamente a SQLite han sido eliminados del código. Este es el primer paso hacia un diseño de base de datos completamente nuevo, pero ahora debemos mirar hacia adelante para ver qué sigue.
Las builds inestables se desactivarán temporalmente esta semana, omitiendo la versión inestable 20250127 para permitir una semana completa de pruebas internas, y se reactivarán para la versión inestable 20250203 la próxima semana. Si usas builds inestables, asegúrate de tener copias de seguridad listas esta semana.
Continúa leyendo para entender exactamente qué significa esto y qué nos depara el futuro.
- JPVenson
Qué hemos hecho exactamente
La publicación de Joshua en noviembre de 2024 describió gran parte de nuestros objetivos. Quiero aprovechar para abordar los comentarios y preguntas recibidas, aclarando algunos puntos clave.
El código anterior incluía múltiples accesos directos a la base de datos SQLite subyacente. SQLite es una base de datos basada en archivos donde Jellyfin almacena la mayoría de sus datos importantes. Esto presentaba 4 problemas principales:
-
El código anterior estaba muy mal escrito
-
El código anterior era extremadamente complejo
-
El código anterior estaba diseñado explícitamente solo para SQLite
-
Las migraciones en el código anterior eran manuales y propensas a errores
Por esto, no podíamos extender la base de datos de forma rápida y confiable para añadir nuevas funcionalidades o mejorar las existentes. El nuevo código utiliza migraciones de EntityFramework, el estándar de la industria para migraciones de bases de datos en el ecosistema C#.
Qué no hemos hecho
Aunque estamos trabajando en ello, el código actual no añade soporte para otros proveedores de bases de datos por sí mismo. Añadir soporte para otros proveedores será un cambio significativo que va más allá de la refactorización, y cuando se implemente, probablemente permanecerá en estado experimental durante bastante tiempo.
Es crucial señalar que aún no hemos optimizado el resto de Jellyfin para trabajar con el nuevo acceso a bases de datos. Esto significa que las builds inestables podrían ser significativamente más lentas mientras reescribimos el resto del código para utilizar las nuevas estructuras.
La nueva arquitectura también permite realizar copias de seguridad adecuadas de instancias de Jellyfin mientras están en ejecución, algo que antes era imposible hacer de forma fiable.
El futuro
Las builds inestables han estado activas durante un tiempo, pero las desactivaremos temporalmente esta semana, omitiendo la versión inestable 20240127 para permitir una semana completa de pruebas internas como Joshua indicó originalmente. Reactivaremos las builds inestables para la semana del 20240203 con estos cambios, así que si usas builds inestables, prepara tus copias de seguridad esta semana.
La migración consolidará la antigua library.db en el archivo jellyfin.db y luego la renombrará a library.db.old, por lo que las builds inestables dejarán de ser compatibles con versiones anteriores.
Para migrar, no admitimos explícitamente versiones anteriores a la 10.10.3. Esto significa que si quieres probar las migraciones, debes comenzar con una base de datos actualizada de la rama 10.10.z o de la versión inestable actual.
Gracias, y si tienes preguntas, no dudes en unirte a nuestros canales de Matrix para obtener ayuda.
- JPVenson.