python - tutorial - sqlalchemy query

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

Question

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

Por ahora, creo un módulo que contiene todas las cosas de 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 asegurarme 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 de modelo que se pueden almacenar de forma independiente sin estropear el mapeador todo el tiempo. Cómo puedo hacer eso ?

Por ahora acabo de ponerlos en el mismo archivo y tengo que crear otro mapeador, pero el primer mapeador 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 mapearla 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 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.

Entonces típicamente hay un db.py o algo similar que tiene la clase Session y el resto del código requerido para configurar la base de datos, incluidos todos los mappers, etc.

Ninguno de los otros módulos, excepto los que realizan operaciones de bases de datos, necesitan 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 puedes crear fácilmente 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 de db , así que no creo que inicializarlos todo el tiempo 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.