La mejor manera de organizar las carpetas que contienen los modelos SQLAlchemy

Question

Utilizo SQLAlchemy en el trabajo y hace el trabajo realmente bien. Ahora estoy pensando en las mejores prácticas.

Por ahora, puedo crear un módulo que sostiene todas las cosas SQLA:

my_model 
     |__ __init__.py 
     |__ _config.py <<<<< contains LOGIN, HOST, and a MetaData instance 
     |__ table1.py <<<<< contains the class, the model and the mapper for table1 
     |__ table2.py <<<<< contains the class, the model and the mapper for table2 
     [...] 

Ahora, realmente no sé si es la mejor manera de hacerlo. Me gustaría cargar las clases con una granularidad fina y asegúrese de crear una conexión solo con el db, etc.

Aquí, todas las clases están separadas, pero todas importan _config y me pregunto si es algo bueno .

Además, me gustaría poder crear subclases de las clases modelo que se pueden almacenar de forma independiente sin tener que jugar con el asignador cada vez. Cómo puedo hacer eso ?

Por ahora acabo de ponerlos en el mismo archivo y tengo que crear otro asignador, pero el primer asignador todavía se llama cada vez. Lo mismo sucedería si tuviera que importar la clase principal porque el asignador se activa en la importación. Si no uso la clase para acceder a los datos, ¿no se sobrecalienta para mapearlos cada vez?

Me gustaría evitar el uso de Elixir también, por favor.

Answer 1

Personalmente, me gusta mantener la lógica de base de datos/ORM fuera de las clases de modelo. Los hace más fáciles de probar. Normalmente tengo algo así como un types.py que define los tipos utilizados en mi aplicación, pero independiente de la base de datos.

A continuación, normalmente hay un algo db.py o similar que tiene la clase Session y el resto del código necesario para configurar la base de datos, incluyendo todos los creadores de mapas etc.

Ninguno de los otros módulos salvo cuando éstas se realizan las operaciones de la base de datos deben importar el módulo db y la existencia de la base de datos está totalmente oculta de la mayoría de las clases de aplicaciones.

Por lo que yo sé, no es fácil crear subclases sin cambiar el asignador. SQLAlchemy no tendrá forma de saber qué subclase recuperar de la base de datos cuando realiza una consulta y debe poder indicar la subclase cuando esté almacenando datos de todos modos.

Realmente no he visto ningún problema al llamar a todos los mapeadores a la vez desde el módulo principal db, así que no creo que inicializarlos sea realmente una preocupación a menos que realmente lo identifiques como un cuello de botella. En mi experiencia, otro procesamiento es un factor mucho más grande que la sobrecarga del mapeador menor.