python - thread - SQLAlchemy: motor, conexión y diferencia de sesión

sqlalchemy thread safe

Question

Uso SQLAlchemy y hay al menos tres entidades: engine , session y connection , que tienen un método de execute , por lo que si, por ejemplo, quiero seleccionar todos los registros de la table , puedo hacer esto

engine.execute(select([table])).fetchall()

y esto

connection.execute(select([table])).fetchall()

e incluso esto

session.execute(select([table])).fetchall()

- Los resultados serán los mismos.

Según tengo entendido, si alguien usa engine.execute crea connection , abre session (Alchemy se encarga de usted) y ejecuta la consulta. Pero, ¿existe una diferencia global entre estas tres formas de realizar una tarea así?

Answer 1

Aquí hay un ejemplo de ejecución de DCL (lenguaje de control de datos) como GRANT

def grantAccess(db, tb, user):
  import sqlalchemy as SA
  import psycopg2

  url = "{d}+{driver}://{u}:{p}@{h}:{port}/{db}"./
            format(d="redshift",
            driver=''psycopg2'',
            u=username,
            p=password,
            h=host,
            port=port,
            db=db)
  engine = SA.create_engine(url)
  cnn = engine.connect()
  trans = cnn.begin()
  strSQL = "GRANT SELECT on table " + tb + " to " + user + " ;"
  try:
      cnn.execute(strSQL)
      trans.commit()
  except:
      trans.rollback()
      raise

Answer 2

La respuesta de Nabeel cubre muchos detalles y es útil, pero me pareció confuso seguirla. Dado que este es actualmente el primer resultado de Google para este problema, agrego mi comprensión para futuras personas que encuentren esta pregunta:

Ejecutando .execute ()

Como observan OP y Nabell Ahmed, al ejecutar un nombre de SELECT * FROM tablename simple, no hay diferencia en el resultado proporcionado.

Las diferencias entre estos tres objetos se vuelven importantes dependiendo del contexto en el que se usa la instrucción SELECT o, más comúnmente, cuando desea hacer otras cosas como INSERT , DELETE , etc.

Cuándo usar Engine, Connection, Session en general

• El motor es el objeto de nivel más bajo utilizado por SQLAlchemy. Mantiene un conjunto de conexiones disponibles para usar cuando la aplicación necesita comunicarse con la base de datos. .execute() es un método de conveniencia que primero llama a conn = engine.connect(close_with_result=True) y luego a conn.execute() . El parámetro close_with_result significa que la conexión se cierra automáticamente. (Estoy parafraseando ligeramente el código fuente, pero esencialmente cierto). editar: Aquí está el código fuente de engine.execute

  Puede usar el motor para ejecutar SQL sin formato.

  result = engine.execute(''SELECT * FROM tablename;'')
  #what engine.execute() is doing under the hood
  conn = engine.connect(close_with_result=True)
  result = conn.execute(''SELECT * FROM tablename;'')
  
  #after you iterate over the results, the result and connection get closed
  for row in result:
      print(result[''columnname'']
  
  #or you can explicitly close the result, which also closes the connection
  result.close()

  Esto está cubierto en los documentos de uso básico .

• La conexión es (como vimos anteriormente) lo que realmente hace el trabajo de ejecutar una consulta SQL. Debe hacer esto siempre que desee un mayor control sobre los atributos de la conexión, cuándo se cierra, etc. Por ejemplo, un ejemplo muy importante de esto es una Transaction , que le permite decidir cuándo confirmar sus cambios en la base de datos. En uso normal, los cambios se confirman automáticamente. Con el uso de transacciones, podría (por ejemplo) ejecutar varias instrucciones SQL diferentes y si algo sale mal con una de ellas, podría deshacer todos los cambios a la vez.

  connection = engine.connect()
  trans = connection.begin()
  try:
      connection.execute("INSERT INTO films VALUES (''Comedy'', ''82 minutes'');")
      connection.execute("INSERT INTO datalog VALUES (''added a comedy'');")
      trans.commit()
  except:
      trans.rollback()
      raise

  Esto le permitiría deshacer ambos cambios si falla uno, como si olvidara crear la tabla de registro de datos.

  Entonces, si está ejecutando código SQL sin procesar y necesita control, use conexiones

• Las sesiones se utilizan para el aspecto de gestión de relaciones de objeto (ORM) de SQLAlchemy (de hecho, puede ver esto desde cómo se importan: from sqlalchemy.orm import sessionmaker ). Utilizan conexiones y transacciones bajo el capó para ejecutar sus declaraciones SQL generadas automáticamente. .execute() es una función de conveniencia que pasa a lo que sea que esté vinculada la sesión (generalmente un motor, pero puede ser una conexión).

  Si está utilizando la funcionalidad ORM, use session; Si solo está haciendo consultas SQL directas no vinculadas a objetos, probablemente sea mejor usar conexiones directamente.

Answer 3

Una descripción general de una línea:

El comportamiento de execute() es el mismo en todos los casos, pero son 3 métodos diferentes, en las clases Engine , Connection y Session .

Qué es exactamente execute() :

Para comprender el comportamiento de execute() debemos analizar la clase Executable . Executable es una superclase para todos los tipos de objetos "enunciados", incluidos select (), delete (), update (), insert (), text (); en palabras más simples posibles, un Executable es una construcción de expresión SQL compatible con SQLAlchemy.

En todos los casos, el método execute() toma el texto SQL o la expresión SQL construida, es decir, cualquiera de la variedad de construcciones de expresiones SQL admitidas en SQLAlchemy y devuelve los resultados de la consulta (un ResultProxy - ResultProxy un objeto cursor DB-API para proporcionar un acceso más fácil a la fila columnas)

Para aclararlo más (solo para aclaración conceptual, no es un enfoque recomendado) :

Además de Engine.execute() (ejecución sin conexión), Connection.execute() y Session.execute() , también es posible utilizar execute() directamente en cualquier construcción Executable . La clase Executable tiene su propia implementación de execute() : según la documentación oficial, una descripción de línea sobre lo que hace execute() es " compilar y ejecutar este Executable ". En este caso, debemos vincular explícitamente el Executable (construcción de expresión SQL) con un objeto Connection o un objeto Engine (que implícitamente obtiene un objeto Connection ), para que execute() sepa dónde ejecutar el SQL .

El siguiente ejemplo lo demuestra bien: dada una tabla como la siguiente:

from sqlalchemy import MetaData, Table, Column, Integer

meta = MetaData()
users_table = Table(''users'', meta,
    Column(''id'', Integer, primary_key=True),
    Column(''name'', String(50)))

Ejecución explícita, es decir, Connection.execute() : pasar el texto SQL o la expresión SQL construida al método execute() de Connection :

engine = create_engine(''sqlite:///file.db'')
connection = engine.connect()
result = connection.execute(users_table.select())
for row in result:
    # ....
connection.close()

Ejecución explícita sin conexión, es decir Engine.execute() : pasar el texto SQL o la expresión SQL construida directamente al método execute() de Engine:

engine = create_engine(''sqlite:///file.db'')
result = engine.execute(users_table.select())
for row in result:
    # ....
result.close()

Ejecución implícita, es decir, Executable.execute() : también no tiene conexión y llama al método execute() del Executable , es decir, llama al método execute() directamente en la construcción de la expresión SQL (una instancia del Executable ).

engine = create_engine(''sqlite:///file.db'')
meta.bind = engine
result = users_table.select().execute()
for row in result:
    # ....
result.close()

Nota: Expresé el ejemplo de ejecución implícita con fines de aclaración, esta forma de ejecución no es muy recomendable, según los docs :

La “ejecución implícita” es un patrón de uso muy antiguo que en la mayoría de los casos es más confuso que útil, y se desaconseja su uso. Ambos patrones parecen alentar el uso excesivo de "atajos" convenientes en el diseño de aplicaciones que conducen a problemas más adelante.

Tus preguntas:

Según tengo entendido, si alguien usa engine.execute, crea conexión, abre sesión (Alchemy se preocupa por usted) y ejecuta la consulta.

Tienes razón para la parte "si alguien usa engine.execute crea connection " pero no para "abre session (Alchemy se preocupa por ti) y ejecuta la consulta" - Usar Engine.execute() y Connection.execute() es (casi) uno lo mismo, en formal, el objeto Connection se crea implícitamente, y en el caso posterior lo instanciamos explícitamente. Lo que realmente sucede en este caso es:

`Engine` object (instantiated via `create_engine()`) -> `Connection` object (instantiated via `engine_instance.connect()`) -> `connection.execute({*SQL expression*})`

Pero, ¿existe una diferencia global entre estas tres formas de realizar dicha tarea?

En la capa DB es exactamente lo mismo, todos ellos están ejecutando SQL (expresiones de texto o varias construcciones de expresiones SQL). Desde el punto de vista de la aplicación, hay dos opciones:

• Ejecución directa: uso de Engine.execute() o Connection.execute()
• Uso de sessions : maneja de manera eficiente las transacciones como una sola unidad de trabajo, con facilidad a través de session.add() , session.rollback() , session.commit() , session.close() . Es la forma de interactuar con la base de datos en el caso de ORM, es decir, tablas mapeadas. Proporciona identidad_mapa para obtener instantáneamente objetos ya accedidos o recién creados / agregados durante una sola solicitud.

Session.execute() finalmente utiliza el método de ejecución de la instrucción Connection.execute() para ejecutar la instrucción SQL. Usar el objeto Session es la forma recomendada de SQLAlchemy ORM para que una aplicación interactúe con la base de datos.

Un extracto de los documentos :

Es importante tener en cuenta que cuando se utiliza el ORQ SQLAlchemy, generalmente no se accede a estos objetos; en cambio, el objeto Session se usa como interfaz para la base de datos. Sin embargo, para las aplicaciones que se basan en el uso directo de sentencias SQL textuales y / o construcciones de expresiones SQL sin la participación de los servicios de gestión de nivel superior del ORM, el motor y la conexión son el rey (y la reina?)