Mejoras en el sistema con la base de datos

[ManuelLR]

Movimiento de código

Desde utils/database.py

Creo que el archivo recoge demasiada información. Según las buenas prácticas de python dice que cada clase en un archivo facilitando el mantenimiento. Esta sería mi propuesta:

• class EmailServer debería moverse a repository/emailServer.py
• class User debería moverse a repository/user.py
• class Account debería moverse a repository/account.py
• def parseAccountsToJson debería moverse a repository/account.py
• def parseJsonToAccounts debería moverse a repository/account.py
• class DBC a repository/repository.py. De esta forma solo habría que llamar a este método. Igualmente creo que habrá que tocar algo para que sea fácil usarlo desde todos los archivos pero cuando se intente unir más seriamente se verá.

Adicionalmente a esto... ¿sería interesante crear la típica sección domain?. Yo tengo el objeto Message dando por ahí la lata que no se donde ponerlo puesto que es algo que no persiste

Desde config/testdb.py

La verdad es que no había planteado ningún sitio para poner los test por lo que esto habría que discutirlo (tanto lugar como como se hacen). Aquí hay dos formas de hacerlo, a lo dp o a lo go. DP ya sabemos como sería, crear una carpeta denominada tests en la raiz e ir organizando todo el código. En cambio, en go los test se ponen en la misma carpeta que el archivo que quieres probar y con el mismo nombre, por ejemplo, los test de services/email.py estarian en services/emailTest.py. A mi sinceramente la forma que más me convence es la de DP así puedes hacer cosas más genéricas y te centras en leer código pero para gustos... los colores.

Conceptos en general

• No existe unión entre los Accounts y los EmailServer. Creo que un account debería de soportar varios EmailServer puesto que el protocolo imap (el más usado para leer), no puede enviar mensajes por lo que haría falta otro y sería desde la misma cuenta.
• No se como funciona la base de datos exactamente pero veo fundamental que haya un id en cada tabla puesto que será lo que le pasaríamos al cliente y nos facilitaría las cosas. Quizás se esté implementando de alguna forma que yo no haya visto.

General

Muy buen diseño, le diste bastantes vueltas la verdad.

Hay una cosa que no acabo de tener clara. ¿Para que poner los getter y los setter?

[juanrarodriguez18]

Resuelta primera parte (Desde utils/database.py) en: 7d9cdfd

[juanrarodriguez18]

Respondiendo a tu último "Check" el "ID" que me demandas lo establecería en el atributo "Name" tanto de la clase "EmailServer" como "Account". El que escogiera el nombre "Name" es debido a que me parecía más cercano a los valores que iba a contener (entendiendo por mi parte un Id algo más como un conjunto de caracteres alfanuméricos aleatorios y/o secuenciales), por lo que me pareció dicha elección de nombre la más acertada.

[juanrarodriguez18]

Respecto a: ¿Para que poner los getter y los setter? Mencionando de nuevo a DP en las clases del "Domain" se tenían y me parecen prácticos para obtener las propiedades de los objetos de la Base de Datos. Quizás pueda ser una forma de programar heredada de Java, pero creo que nos pueden servir de ayuda el tenerlos y mantenerlos.

[ManuelLR]

Respondiendo a tu último "Check" el "ID" que me demandas lo establecería en el atributo "Name" tanto de la clase "EmailServer" como "Account". El que escogiera el nombre "Name" es debido a que me parecía más cercano a los valores que iba a contener (entendiendo por mi parte un Id algo más como un conjunto de caracteres alfanuméricos aleatorios y/o secuenciales), por lo que me pareció dicha elección de nombre la más acertada.

Te explico un poco la teoría de Telegram para que sepas por donde voy. Todos los usuarios(incluidos los bots) tienen su id (carácteres numéricos y únicos en todo Telegram) y su nombre de usuario (que pueden tenerlo o no y si, son únicos pero pueden variar).
Teniendo esto claro te explico mi forma de verlo y tú ya me comentas.

EmailServer

El valor único no será el nombre. Ten en cuenta que otro usuario podría darle el mismo nombre y... ahora que?. El conjunto de valores únicos sería el Host, Port y Protocol por lo que sería mandar prácticamente toda la tabla además de que nos asecha el error del límite de longitud del mensaje.

Account

Este es cierto que por el atributo Name sería suficiente (tecnicamente y si nos ponemos tiquismiquis podrían repetirse y sería necesario un id) pero, si le damos un id solventariamos el problema de límite de longitud del mensaje (#1)

En función a todo esto ya valoras y decides que te parece mejor

[ManuelLR]

Respecto a: ¿Para que poner los getter y los setter? Mencionando de nuevo a DP en las clases del "Domain" se tenían y me parecen prácticos para obtener las propiedades de los objetos de la Base de Datos. Quizás pueda ser una forma de programar heredada de Java, pero creo que nos pueden servir de ayuda el tenerlos y mantenerlos.

En python no suele ser lo habitual la verdad y... en DP tiene su motivo. Al usar hibernate en modo lazy no cogia todas las propiedades del objeto de la DB solo algunas así que al usar el get podía hacer la petición. No creo que en este repo lleguemos a ese punto pero igualmente python tiene una solución que es la anotación @xxxx.setter como puedes ver en este artículo. Así queda el código igual de bonito y útil sin necesidad de getter y setter.

Reitero lo mismo, lo que prefieras.

[ManuelLR]

Por cierto, deberíamos usar las mismas normas de estilo. Yo uso las que me marca PyCharm que sigue el estandar de python. Te hago un resumen rápido que creo que será suficiente y ya valoras si te merece la pena cambiar el código:

• Las clases empiezan con mayúsculas lo que indica que siguen la metodología de nombramientos de java. EsteEsElNombreDeUnaClase
• Los métodos (def) empiezan en minúscula lo que indica que se separan por _. este_es_el_nombre_de_un_def
• Los "imports", las variables, los métodos y las clases escritas en la "raiz" suelen llevar doble tabulación para separarlas entre ellas mientras que los escritos dentro de una clase llevan únicamente una tabulación. Evidentemente, si estamos definiendo muchos "imports" o variables junt@s podremos ponerlos sin doble tabulación.
• Los nombre de los archivos xx.py se escriben en mayúsculas siguiendo la misma regla de nombres que los métodos

[ManuelLR]

que queda de este issue?

[juanrarodriguez18]

Yo por mi la cerraría.