Estoy tratando de crear una aplicación de back-end usando FastApi y sqlAchemy. Tengo muchas entidades que tienen relaciones con la base de datos. Entonces, mi pregunta es: ¿Cómo acelerar el desarrollo? Ahora escribo para cada código de entidad:
@app.get("/holidays") def getHolidays(): session = Session(bind=engine) holidays: List[Holiday] = session.query(Holiday).all() return [x.to_json() for x in holidays] @app.get("/exclusive_operations") def getExclusiveOperations(): session = Session(bind=engine) exclusive_operations: List[ExclusiveOperation] = session.query(ExclusiveOperation).all() return [x.to_json() for x in exclusive_operations] @app.get('/category_descriptions') def getCategoryDescr(): session = Session(bind=engine) category_descrs: List[CategoryDescr] = session.query(CategoryDescr).all() return [x.to_json() for x in category_descrs]Entonces, si quiero crear todas las operaciones crudas, necesito crear 12 métodos típicos para 3 entidades. ¿Quizás exista otra solución?
Es Python: como lenguaje dinámico, las funciones y los métodos se crean en tiempo de ejecución. El decorador "@app.get" es lo que registra sus vistas en la aplicación, no su existencia en el nivel superior de un módulo.
Por lo tanto, puede crear un bucle for que simplemente recree y registre la vista para cada una de sus entidades; se puede hacer a nivel de módulo o dentro de una función.
(es bueno tener en cuenta que la sintaxis del decorador "@xxxx" es solo azúcar de sintaxis para llamar al decorador pasando la función decorada como su único parámetro)
for Entity, name in [(Holiday, "holidays"), (ExclusiveOperation, "exclusive_operations"), (CategoryDescr, "category_descriptions")]: def freeze_var_wrapper(Entity, name): # this intermediary function is needed, otherwise the Entity and name # variables would be always up-to-date inside the view function # and always point to the last value in the external for-loop after # it finished execution: def view(): session = Session(bind=engine) entities = session.query(Entity).all() return [x.to_json() for x in entities] # optional, may facilitate debugging: view.__name__ = f"get{Entity.__name__}s" # actually registers the view function with the framework: # (could be done in the same line, without the "view_registrer" var) view_registrer = app.get(f"/{name}") view_registrer(view) freeze_var_wrapper(Entity, name) Hay otras formas de hacer esto que podrían eliminar el patrón y parecer más elegantes, por ejemplo, con herencia de clase y una __init__subclass__ en una clase base (incluso si el marco no usa "vistas de clase", registraremos el límite método para cada clase, que es solo un invocable):
class BaseView: Entity: cls view_name: str def __init_subclass__(cls, *args, **kw): super().__init_subclass__(*args, **kw) app.get(f"/{cls.view_name}")(cls.view) # above, cls.view is bound to the subclass being processed, therefore # the class attributes as defined in each class body are used inside the method # this could easily register post, delete and detail views as well @classmethod def view(cls); session = Session(bind=engine) entities = session.query(cls.Entity).all() return [x.to_json() for x in entities] class HolydayView(BaseView): Entity = Holyday view_name = "holydays" # thats is just it. class ExclusiveOperationView(BaseView): Entity = ExclusiveOperation view_name = "exclusive_operations" class CatewgoryDescriptionView(BaseView): Entity = CategoryDescription view_name = "category_descriptions"