[ethicapp-v2/api-v2] Recreación del esquema de base de datos con sequelize

[claudio-alvarez]

Descripción general

Vamos a recrear el schema de base de datos utilizando sequelize. Haremos ciertas modificaciones al schema, de manera que las tablas que guardan contenido como preguntas y respuestas sean una sola, y éstas contengan una columna de tipo json/jsonb para almacenar estos contenidos como objetos, en vez de tener tablas separadas como ocurre en el schema en ethicapp-v2.

Para esto sería adecuado:

• Generar un listado de las tablas (sus nombres) que tiene la base de datos en ethicapp-v2 (adjuntar archivo .txt a este issue, dar nombre ethicapp-v2-dbtables.txt).
• Generar un listado de la nueva propuesta de tablas (sus nombres; adjuntar archivo .txt a este issue, dar nombre ethicapp-v2-api-v2-dbtables.txt).
• Agregar enlaces o adjuntar archivos que permitan ver las modificaciones al schema.

¿Cuándo se usaría?

La reimplementación de la base de datos utilizando sequelize permite utilizar migraciones para controlar la evolución de la base de datos, y brinda una serie de herramientas que facilitan la mantenibilidad de ella. Además, sequelize provee una interfaz de consulta que serviría para flexibilizar la implementación de endpoints de API y hacerla en forma segura y compatible con el último módulo de node-postgres (pg).

[benjamin-gonzalez-diaz]

lista de las tablas antiguas de la base de datos. (archivo de texto)

ethicapp-v2-dbtables.txt

lista de las tablas Nuevas de la base de datos

ethicapp-v2-api-v2-dbtables.txt

imagenes de las base de datos

Antigua: Nueva: parte de alumno:

[claudio-alvarez]

En la lista depurada (tablas eliminadas), falta listar tablas que efectivamente se propone borrar. Dentro de las tablas a eliminar:

• teacher_account_requests: no podemos borrarla, pues es parte de la funcionalidad de flujo de creación de cuentas de profesor. Es creada en create_37.sql
• pass_reset: tenemos que averiguar si la funcionalidad de recuperación de contraseña la está usando actualmente. Para esto, es necesario mirar los endpoints que la estén usando, e incluso verificar en frontend cuáles de éstos son llamados realmente.
• mail_domain: analizar qué código de endpoints en backend accede a esta tabla, ¿son estos endpoints llamados desde el frontend de admin-panel o de EthicApp?
• report (o reports?): ¿Es realmente desechable esta tabla? Necesitamos mismo análisis; qué endpoints acceden y si estos endpoints son llamados desde el frontend.
• jigsaw, jigsaw_role, jigsaw_users: Dejémoslas, pues necesitaremos diseñar próximamente cómo hacer funcionar actividades con juego de roles (jigsaw), y los datos en ella serán punto de partida.
• ideas: Es eliminable, EthicApp no la usa.
• semantic_unit: Es eliminable.
• semantic_document: También podría ser eliminable, pues "documents" existe. Necesitaríamos verificar que "documents" es la tabla que se usa en EthicApp.
• differential_selection: Pareciera ser una tabla dedicada a las respuestas de diferencial semántico. La idea es que la tabla responses contenga esto.
• selection: Pareciera ser una tabla utilizada por una actividad obsoleta (unidades semánticas). Ver si hay endpoints de EthicApp que la usen (no creo).
• criteria, criteria_selection: Tenemos que analizar estas tablas. ¿Qué endpoints las usan? ¿son éstos accedidos desde el frontend de EthicApp?
• overlays: Es utilizado por un tipo de actividad que está obsoleto. EthicApp no usa overlays en textos.
• rubricas: Es eliminable, pues EthicApp no usa rúbricas.
• drafts: Analizar qué endpoints la usan, ver si endpoints son invocados desde frontend de EthicApp.

[benjamin-gonzalez-diaz]

ethicapp-v2-api-v2-dbtables-final.txt

[claudio-alvarez]

Queda aprobada la propuesta de modificación al diseño de schema, puedes continuar la implementación de las migraciones con Sequelize.

[claudio-alvarez]

@benjamin-gonzalez-diaz, puedes crear un PR para ir avanzando en esto, dado que desde un issue no podemos hacer review del código. Observo un par de detalles:

1. Tenemos que analizar si sequelize permite distintos seeds diferenciados por ambiente. Si has creado seeders, por ejemplo, para la tabla stage, éstos tendrían que quedar para ambiente de desarrollo de acuerdo a lo que vemos en los commits. Tenemos una variable de entorno en EthicApp (mira el .env) que define esto; tendríamos que ver si compatibiliza con la forma de trabajar en sequelize.
2. Evitemos replicar la práctica de ponerle nombre create_xx a las migraciones; más bien, procuremos ponerles nombres semánticos como se hace con otros frameworks (ActiveRecord). Si vas a agregar una tabla Stages, la clase debería llamarse CreateStagesTable probablemente, o si vas a agregar una columna, AddColumnToTable, etc.

[benjamin-gonzalez-diaz]

[claudio-alvarez]

Podríamos adoptar un par de convenciones de nombres para mayor consistencia:

• Todos los nombres de tablas en minúsculas y en plural.
• Todos los atributos en snake_case

Incluso, hay algunas tablas cuyos nombres podríamos perfeccionar, por ejemplo:

• sesusers, podría llamarse sessions_users, pues es una tabla de unión.

También podríamos perfeccionar los nombres de las claves foráneas, adoptemos la convención de nombrar la FK con el nombre de la tabla a la que hace referencia, en singular, con sufijo id, por ejemplo, si la FK referencia "users", la FK tendría que llamarse user_id.

[claudio-alvarez]

Ojo con los atributos de modelName y tableName cuando creamos modelos! Si no somos consistentes, tendremos problemas después al utilizar la interfaz de consultas de sequelize. Aquí hay una descripción sobre los dos campos anteriores, con un ejemplo:

https://chat.openai.com/share/44478ecb-bc08-4730-9567-3032592efe44

[claudio-alvarez]

Implementado y revisado en PR #301.