#949 closed task (fixed)
Migración de repositorios a bases de datos
| Reported by: | Víctor de Buen Remiro | Owned by: | Víctor de Buen Remiro |
|---|---|---|---|
| Priority: | highest | Milestone: | TOL Packages |
| Component: | Kernel | Version: | |
| Severity: | blocker | Keywords: | |
| Cc: | Pedro Gea, Jorge |
Description
El actual sistema de repositorios de paquetes basados en directorios remotos con fichero de índice en ASCII no facilita la actualización, modificación, alta y baja de paquetes sueltos y no garantiza la integridad referencial, especialmente en caso de accesos simultáneos.
Para solucionar este tipo de problemas la forma más natural es utilizar una base de datos pues de seguir evolucionando el sistema actual casi habría que reinventarlas.
El nuevo sistema de repositorios deberá convivir un tiempo con el actual por lo que lo mejor será crearlo como un nuevo NameBlock TolPackagesDb que replique los comportamientos de la parte cliente de forma que los cambios sean mínimos para los usuarios, pero que aporte una API del lado servidor más fácil de usar y mucho más robusta que incluiría al menos estas características:
//Crea el .oza + los recursos + el register y lo comprime en un zip
Real TolPackageDb::Server::CreateLocalPackage(Text sourcePath, Text destinPath);
Class TolPackageDb::Server::@Repository
{
@DBConnection _.connection;
//Extrae el register del .zip y ejecuta las queries de inserción
Real Upload(Text packagePath);
//Extrae el register del .zip y ejecuta las queries de borrado
//Si no se pasa número de versión se borra todo.
Real Remove(Text package);
Static New(parámetros de conexión)
};
En principio no habría necesidad de eliminar la posibilidad de que un usuario externo siguiera creando y manteniendo sus propios repositorios basados en directorios y ficheros ASCII pues si estos no son muy grandes y no hay muchos desarrolladores es un sistema más que suficiente. Ambos tipos de repositorios pueden convivir sin problemas pero lo que no se va a hacer es tener replicado para siempre el repositorio oficial de tol-project, sino que pasado un corto periodo de adaptación se quedará únicamente el de base de datos.
Por motivos de seguridad la parte cliente no debe tener acceso directo a la base de datos del repositorio sino que se debe hacer de forma indirecta usando algún script tipo PHP que cree las consultas a partir de una URL con el formato adecuado.
Además de la información auxiliar del paquete (fecha, descripción, versión, etc.) la tabla principal deberá contener en cada registro el paquete propiamente dicho, es decir, el fichero .zip incrustado en un campo blob.
Change History (8)
comment:1 Changed 15 years ago by
| Cc: | Pedro Gea Jorge added |
|---|---|
| Status: | new → accepted |
comment:2 Changed 14 years ago by
comment:4 Changed 14 years ago by
LastCompatible no usa el conjunto TolPackage::Client::@Repository::_.allPackages sino el propio directorio TolPackage::Client::_.localRoot para buscar la última versión disponible localmente para un paquete dado
El nuevo método InstallFromLocalZip Instala un paquete desde un archivo local comprimido con extensión .zip
comment:5 Changed 14 years ago by
comment:7 Changed 14 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | accepted → closed |
comment:8 Changed 14 years ago by
Ver detalles de las solucciones en https://www.tol-project.org/wiki/TolPackageRulesAndComments
(In [2567]) Refs #949
Funcoines de codificación en Base64