Code

tiforadacaixa

conectando SqlAlchemy com bases de dados PostgreSql MySQL Oracle MSSQL e SQLite

walter silva novembro 13, 2019

Configuração do mecanismo 

O Engineé o ponto de partida para qualquer aplicativo SQLAlchemy. É a "base" para o banco de dados real e seu DBAPI , entregue ao aplicativo SQLAlchemy por meio de um conjunto de conexões e a Dialect, que descreve como conversar com um tipo específico de combinação de banco de dados / DBAPI.
A estrutura geral pode ser ilustrada da seguinte maneira:
../_images/sqla_engine_arch.png
Onde acima, um faz Enginereferência a Dialecte a Pool, que juntos interpretam as funções do módulo DBAPI, bem como o comportamento do banco de dados.
Criar um mecanismo é apenas uma questão de emitir uma única chamada create_engine():
from sqlalchemy import create_engine
engine = create_engine('postgresql://scott:tiger@localhost:5432/mydatabase')
O mecanismo acima cria um Dialectobjeto adaptado ao PostgreSQL, bem como um Poolobjeto que estabelecerá uma conexão DBAPI no localhost:5432momento em que uma solicitação de conexão for recebida pela primeira vez. Note-se que a Engineea sua subjacente Poolque não estabelecer a primeira ligação DBAPI real até que o Engine.connect() método é chamado, ou uma operação que é dependente deste método tal como Engine.execute()é invocado. Dessa maneira, Enginee Poolpode-se dizer que possui um comportamento de inicialização lento .
O Engine, uma vez criado, pode ser usado diretamente para interagir com o banco de dados ou pode ser passado para um Sessionobjeto para trabalhar com o ORM. Esta seção cobre os detalhes da configuração de um Engine. A próxima seção, Trabalhando com mecanismos e conexões , detalhará a API de uso do Enginee similares, geralmente para aplicativos não-ORM.

Bancos de dados suportados 

O SQLAlchemy inclui muitas Dialectimplementações para vários back-ends. Dialetos para os bancos de dados mais comuns estão incluídos no SQLAlchemy; alguns outros requerem uma instalação adicional de um dialeto separado.
Consulte a seção Dialetos para obter informações sobre os vários back-end disponíveis.

URLs do banco de dados 

A create_engine()função produz um Engineobjeto com base em uma URL. Esses URLs seguem o RFC-1738 e geralmente podem incluir nome de usuário, senha, nome do host, nome do banco de dados, além de argumentos opcionais de palavras-chave para configurações adicionais. Em alguns casos, um caminho de arquivo é aceito e, em outros, um "nome da fonte de dados" substitui as partes "host" e "banco de dados". A forma típica de uma URL de banco de dados é:
dialect+driver://username:password@host:port/database
Nomes dialeto incluir o nome de identificação do dialeto SQLAlchemy, um nome como sqlite, mysql, postgresql, oracle, ou mssql. O nome do driv é o nome da DBAPI a ser usada para conectar-se ao banco de dados usando todas as letras minúsculas. Se não especificado, um DBAPI "padrão" será importado, se disponível - esse padrão geralmente é o driver mais conhecido disponível para esse back-end.
Como o URL é como qualquer outro URL, caracteres especiais, como os que podem ser usados ​​na senha, precisam ser codificados em URL. Abaixo está um exemplo de um URL que inclui a senha "kx%jj5/g":
postgresql+pg8000://dbuser:kx%25jj5%2Fg@pghost10/appdb
A codificação para a senha acima pode ser gerada usando urllib:
>>> import urllib.parse
>>> urllib.parse.quote_plus("kx%jj5/g")
'kx%25jj5%2Fg'
Exemplos de estilos de conexão comuns seguem abaixo. Para obter um índice completo de informações detalhadas sobre todos os dialetos incluídos, bem como links para dialetos de terceiros, consulte Dialetos .

PostgreSQL 

O dialeto do PostgreSQL usa psycopg2 como DBAPI padrão. O pg8000 também está disponível como um substituto do Python puro:
# default
engine = create_engine('postgresql://scott:tiger@localhost/mydatabase')

# psycopg2
engine = create_engine('postgresql+psycopg2://scott:tiger@localhost/mydatabase')

# pg8000
engine = create_engine('postgresql+pg8000://scott:tiger@localhost/mydatabase')
Mais notas sobre a conexão com o PostgreSQL no PostgreSQL .

MySQL 

O dialeto do MySQL usa mysql-python como DBAPI padrão. Existem muitos DBAPIs do MySQL disponíveis, incluindo o MySQL-connector-python e o OurSQL:
# default
engine = create_engine('mysql://scott:tiger@localhost/foo')

# mysqlclient (a maintained fork of MySQL-Python)
engine = create_engine('mysql+mysqldb://scott:tiger@localhost/foo')

# PyMySQL
engine = create_engine('mysql+pymysql://scott:tiger@localhost/foo')
Mais notas sobre a conexão com o MySQL no MySQL .

Oracle 

O dialeto Oracle usa cx_oracle como o DBAPI padrão:
engine = create_engine('oracle://scott:tiger@127.0.0.1:1521/sidname')

engine = create_engine('oracle+cx_oracle://scott:tiger@tnsname')
Mais notas sobre a conexão com o Oracle na Oracle .

Microsoft SQL Server 

O dialeto do SQL Server usa pyodbc como DBAPI padrão. pymssql também está disponível:
# pyodbc
engine = create_engine('mssql+pyodbc://scott:tiger@mydsn')

# pymssql
engine = create_engine('mssql+pymssql://scott:tiger@hostname:port/dbname')
Mais notas sobre a conexão com o SQL Server no Microsoft SQL Server .

SQLite 

O SQLite se conecta a bancos de dados baseados em arquivos, usando o módulo interno do Python sqlite3por padrão.
Como o SQLite se conecta aos arquivos locais, o formato da URL é um pouco diferente. A parte "arquivo" da URL é o nome do arquivo do banco de dados. Para um caminho de arquivo relativo, isso requer três barras:
# sqlite://<nohostname>/<path>
# where <path> is relative:
engine = create_engine('sqlite:///foo.db')
E para um caminho de arquivo absoluto, as três barras são seguidas pelo caminho absoluto:
# Unix/Mac - 4 initial slashes in total
engine = create_engine('sqlite:////absolute/path/to/foo.db')

# Windows
engine = create_engine('sqlite:///C:\\path\\to\\foo.db')

# Windows alternative using raw string
engine = create_engine(r'sqlite:///C:\path\to\foo.db')
Para usar um banco de :memory:dados SQLite , especifique um URL vazio:
engine = create_engine('sqlite://')
Mais notas sobre a conexão com o SQLite no SQLite .

Outros 

Consulte Dialetos , a página de nível superior para toda a documentação adicional de dialetos.

API de criação de mecanismo 

sqlalchemy.create_engine( * args , ** kwargs ) 
Crie uma nova Engineinstância.
O formulário de chamada padrão é enviar a URL como o primeiro argumento posicional, geralmente uma sequência que indica o dialeto do banco de dados e os argumentos de conexão:
engine = create_engine("postgresql://scott:tiger@localhost/test")
Argumentos de palavras-chave adicionais podem segui-lo, estabelecendo várias opções nos resultados Engine e seus subjacentes Dialecte Pool construções:
engine = create_engine("mysql://scott:tiger@hostname/dbname",
                            encoding='latin1', echo=True)
A forma de cadeia de caracteres do URL é dialect[+driver]://user:password@host/dbname[?key=value..], onde dialecté um nome de banco de dados, tais como mysql, oracle, postgresql, etc., e drivero nome de um DBAPI, tais como psycopg2, pyodbc, cx_oracle, etc. Em alternativa, o URL pode ser um exemplo de URL.
**kwargsrequer uma ampla variedade de opções que são roteadas para seus componentes apropriados. Os argumentos podem ser específicos para o Engine, o subjacente Dialecte o Pool. Dialetos específicos também aceitam argumentos de palavras-chave exclusivos desse dialeto. Aqui, descrevemos os parâmetros comuns à maioria dos create_engine()usos.
Uma vez estabelecido, o recém-resultante Enginesolicitará uma conexão do subjacente Pooluma vez Engine.connect()chamado, ou um método que dependa dele, como Engine.execute()é chamado. Por Poolsua vez, estabelecerá a primeira conexão DBAPI real quando essa solicitação for recebida. A create_engine()chamada em si não estabelece nenhuma conexão DBAPI real diretamente.
Veja também
Configuração do mecanismo
Dialetos
Trabalhando com motores e conexões
Parâmetros
  • case_sensitive = True  - se False, os nomes das colunas de resultados corresponderão de maneira que não diferencia maiúsculas de minúsculas, ou seja row['SomeColumn'],.
  • connect_args  - um dicionário de opções que serão passadas diretamente para o connect()método da DBAPI como argumentos adicionais de palavras-chave. Veja o exemplo em argumentos DBAPI customizados connect () .
  • convert_unicode = Falso  -
    se definido como True, faz com que todos os Stringtipos de dados ajam como se o String.convert_unicodesinalizador tivesse sido definido como True, independentemente da configuração de Falseum String tipo individual . Isso tem o efeito de fazer Stringcom que todas as colunas com base acomodem objetos Python Unicode diretamente como se o tipo de dados fosse o Unicodetipo.
    Descontinuado desde a versão 1.3: O create_engine.convert_unicodeparâmetro está descontinuado e será removido em uma versão futura. Todas as DBAPIs modernas agora suportam Python Unicode diretamente e esse parâmetro é desnecessário.
  • criador  - um exigível que retorna uma conexão DBAPI. Essa função de criação será passada para o conjunto de conexões subjacente e será usada para criar todas as novas conexões com o banco de dados. O uso dessa função faz com que os parâmetros de conexão especificados no argumento da URL sejam ignorados.
  • eco = Falso  -
    se True, o mecanismo registrará todas as instruções e uma repr()de suas listas de parâmetros no manipulador de log padrão, cujo padrão é a sys.stdoutsaída. Se definido como a sequência "debug", as linhas de resultado também serão impressas na saída padrão. O echoatributo de Enginepode ser modificado a qualquer momento para ativar e desativar o log; O controle direto do log também está disponível usando o loggingmódulo Python padrão .
    Veja também
    Configurando o log - mais detalhes sobre como configurar o log.
  • echo_pool = False  -
    se True, o conjunto de conexões registrará a saída informativa, como quando as conexões são invalidadas e quando as conexões são recicladas para o manipulador de log padrão, cujo padrão é a sys.stdoutsaída. Se definido como a sequência "debug", o registro incluirá check-out e check-in de pool. O controle direto do log também está disponível usando o loggingmódulo Python padrão .
    Veja também
    Configurando o log - mais detalhes sobre como configurar o log.
  • empty_in_strategy  -
    A estratégia de compilação SQL a ser usada ao renderizar uma expressão IN ou NOT IN para ColumnOperators.in_() onde o lado direito é um conjunto vazio. Este é um valor de cadeia que pode ser um dos static, dynamicou dynamic_warn. A static estratégia é o padrão, e uma comparação IN com um conjunto vazio gerará uma expressão falsa simples “1! = 1”. A dynamic estratégia se comporta como a do SQLAlchemy 1.1 e anterior, emitindo uma expressão falsa do formato "expr! = Expr", que tem o efeito de avaliar para NULL no caso de uma expressão nula. dynamic_warné o mesmo que dynamic, no entanto, também emite um aviso quando um conjunto vazio é encontrado; isso porque a comparação "dinâmica" geralmente apresenta um desempenho ruim na maioria dos bancos de dados.
    Novo na versão 1.2: adicionada a empty_in_strategyconfiguração e, adicionalmente, padronizou o comportamento para comparações IN de conjunto vazio a uma expressão booleana estática.
  • codificação  -
    O padrão é utf-8. Essa é a codificação de seqüência de caracteres usada pelo SQLAlchemy para operações de codificação / decodificação de seqüência de caracteres que ocorrem no SQLAlchemy, fora do DBAPI. As DBAPIs mais modernas apresentam algum grau de suporte direto a unicodeobjetos Python , o que você vê no Python 2 como uma sequência do formulário . Para os cenários em que o DBAPI é detectado como não suportando um objeto Python , essa codificação é usada para determinar a codificação de origem / destino. Não é usado para os casos em que o DBAPI manipula diretamente o unicode.u'some string'unicode
    Para configurar corretamente um sistema para acomodar unicodeobjetos Python , a DBAPI deve ser configurada para manipular o unicode da maneira mais apropriada possível - consulte as notas sobre o unicode pertencentes ao banco de dados de destino específico em uso em Dialects .
    As áreas em que a codificação de seqüência de caracteres pode precisar ser acomodada fora do DBAPI incluem zero ou mais de:
    • os valores passados ​​para os parâmetros associados, correspondentes ao Unicodetipo ou Stringtipo quando convert_unicodeé True;
    • os valores retornados nas colunas do conjunto de resultados correspondentes ao Unicodetipo ou String quando convert_unicodeé True;
    • a instrução SQL da cadeia de caracteres transmitida ao cursor.execute()método da DBAPI ;
    • os nomes das cadeias de caracteres das chaves no dicionário de parâmetros vinculados passados ​​para os DBAPI's cursor.execute() e para os cursor.setinputsizes()métodos;
    • os nomes da coluna da sequência recuperados do cursor.descriptionatributo da DBAPI .
    Ao usar o Python 3, o DBAPI é necessário para suportar todos os valores acima como unicodeobjetos Python , que no Python 3 são conhecidos como str. No Python 2, o DBAPI não especifica o comportamento unicode, portanto, o SQLAlchemy deve tomar decisões para cada um dos valores acima em uma base por DBAPI - as implementações são completamente inconsistentes em seu comportamento.
  • activation_options  - Opções de execução de dicionário que serão aplicadas a todas as conexões. Vejo execution_options()
  • hide_parameters  -
    Booleano, quando definido como True, os parâmetros da instrução SQL não serão exibidos no log INFO nem serão formatados na representação de seqüência de StatementErrorobjetos.
    Novo na versão 1.3.8.
  • implicit_returning = True  - Quando True, uma construção compatível com RETURNING, se disponível, será usada para buscar novos valores de chave primária gerados quando uma instrução INSERT de uma única linha for emitida sem a cláusula return () existente. Isso se aplica aos back-end que suportam RETURNING ou uma construção compatível, incluindo PostgreSQL, Firebird, Oracle, Microsoft SQL Server. Configure Falsepara desativar o uso automático de RETURNING.
  • isolation_level  -
    esse parâmetro de cadeia é interpretado por vários dialetos para afetar o nível de isolamento da transação da conexão com o banco de dados. O parâmetro essencialmente aceita algum subconjunto desses argumentos de cadeia: "SERIALIZABLE", "REPEATABLE_READ", "READ_COMMITTED", "READ_UNCOMMITTED"e "AUTOCOMMIT". O comportamento aqui varia de acordo com o back-end e os dialetos individuais devem ser consultados diretamente.
    Observe que o nível de isolamento também pode ser definido Connectiontambém, usando o Connection.execution_options.isolation_level recurso.
    Veja também
    Connection.default_isolation_level - visualizar nível padrão
    Connection.execution_options.isolation_level - definido por Connectionnível de isolamento
    Isolamento de Transações SQLite
    Isolamento de Transação PostgreSQL
    Isolamento de Transação MySQL
    Definindo níveis de isolamento de transação - para o ORM
  • json_deserializer  -
    para dialetos que suportam o JSON tipo de dados, é uma chamada de Python que converterá uma string JSON em um objeto Python. Por padrão, a json.loadsfunção Python é usada.
    Alterado na versão 1.3.7: O dialeto SQLite renomeou isso de _json_deserializer.
  • json_serializer  -
    para dialetos que suportam o JSON tipo de dados, é uma chamada de Python que renderiza um determinado objeto como JSON. Por padrão, a json.dumpsfunção Python é usada.
    Alterado na versão 1.3.7: O dialeto SQLite renomeou isso de _json_serializer.
  • label_length = None  -
    valor inteiro opcional que limita o tamanho dos rótulos das colunas geradas dinamicamente a muitos caracteres. Se menor que 6, os rótulos são gerados como "_ (contador)". Se for usado Noneo valor de dialect.max_identifier_length, que pode ser afetado pelo create_engine.max_identifier_lengthparâmetro. O valor de create_engine.label_length não pode ser maior que o de create_engine.max_identfier_length.
    Veja também
    create_engine.max_identifier_length
  • listeners  - Uma lista de um ou mais PoolListenerobjetos que receberão eventos do conjunto de conexões.
  • logging_name  - identificador de string que será usado no campo "nome" dos registros de log gerados no logger "sqlalchemy.engine". O padrão é uma cadeia de caracteres hexadecimal da identificação do objeto.
  • max_identifier_length  -
    inteiro; substitua o max_identifier_length determinado pelo dialeto. se Noneou zero, não tem efeito. Esse é o número máximo configurado de caracteres do banco de dados que pode ser usado em um identificador SQL, como nome da tabela, nome da coluna ou nome do rótulo. Todos os dialetos determinam esse valor automaticamente, no entanto, no caso de uma nova versão do banco de dados para a qual esse valor foi alterado, mas o dialeto de SQLAlchemy não foi ajustado, o valor pode ser passado aqui.
    Novo na versão 1.3.9.
    Veja também
    create_engine.label_length
  • max_overflow = 10  - o número de conexões a serem permitidas no “overflow” do conjunto de conexões, ou seja, as conexões que podem ser abertas acima e além da configuração pool_size, cujo padrão é cinco. isso é usado apenas com QueuePool.
  • module = None  - referência a um objeto de módulo Python (o próprio módulo, não o nome da string). Especifica um módulo DBAPI alternativo a ser usado pelo dialeto do mecanismo. Cada sub-dialeto faz referência a um DBAPI específico que será importado antes da primeira conexão. Este parâmetro faz com que a importação seja ignorada e o módulo fornecido seja usado. Pode ser usado para testar DBAPIs, bem como para injetar implementações de DBAPI "falsas" no Engine.
  • paramstyle = None  - O paramstyle a ser usado ao renderizar parâmetros vinculados. O estilo padrão é o recomendado pelo próprio DBAPI, que é recuperado do .paramstyleatributo do DBAPI. No entanto, a maioria dos DBAPIs aceita mais de um parâmetro e, em particular, pode ser desejável alterar um parâmetro nomeado para um posicional, ou vice-versa. Quando este atributo é passado, deve ser um dos valores "qmark", "numeric", "named", "format"ou "pyformat", e deve corresponder a um estilo de parâmetro conhecido para ser suportado pela DBAPI em utilização.
  • pool = None  - uma instância já construída de Pool, como uma QueuePoolinstância. Se não for None, esse pool será usado diretamente como o pool de conexão subjacente do mecanismo, ignorando quaisquer parâmetros de conexão presentes no argumento URL. Para obter informações sobre a construção de conjuntos de conexões manualmente, consulte Pool de conexões .
  • poolclass = None  - uma Pool subclasse, que será usada para criar uma instância do pool de conexão usando os parâmetros de conexão fornecidos na URL. Observe que isso difere de poolque, na verdade, você não instancia o pool, apenas indica que tipo de pool deve ser usado.
  • pool_logging_name  - identificador de string que será usado no campo "name" dos registros de log gerados no logger "sqlalchemy.pool". O padrão é uma cadeia de caracteres hexadecimal da identificação do objeto.
  • pool_pre_ping  -
    booleano, se True habilitará o recurso de "pré-ping" do conjunto de conexões que testa as conexões quanto à disponibilidade em cada check-out.
    Novo na versão 1.2.
    Veja também
    Manipulação de desconexão - pessimista
  • pool_size = 5  - o número de conexões a serem mantidas abertas dentro do conjunto de conexões. Isso é usado QueuePooltanto quanto SingletonThreadPool. Com QueuePool, uma pool_sizeconfiguração de 0 indica sem limite; para desativar o pool, defina poolclasscomo em NullPoolvez disso.
  • pool_recycle = -1  -
    essa configuração faz com que o pool recicle as conexões após o número especificado de segundos. O padrão é -1 ou nenhum tempo limite. Por exemplo, definir 3600 significa que as conexões serão recicladas após uma hora. Observe que o MySQL, em particular, será desconectado automaticamente se nenhuma atividade for detectada em uma conexão por oito horas (embora isso possa ser configurado com a própria conexão MySQLDB e com a configuração do servidor).
    Veja também
    Definir reciclagem de pool
  • pool_reset_on_return = 'reversão'  -
    ajustar o Pool.reset_on_returnparâmetro do subjacente Poolobjecto, o qual pode ser ajustado para os valores "rollback", "commit", or None.
    Veja também
    Pool.reset_on_return
  • pool_timeout = 30  - número de segundos para esperar antes de desistir de obter uma conexão da piscina. Isso é usado apenas com QueuePool.
  • pool_use_lifo = Falso  -
    use LIFO (último a entrar, primeiro a sair) ao recuperar conexões em QueuePoolvez de FIFO (primeiro a entrar, primeiro a sair). Usando o LIFO, um esquema de tempo limite do servidor pode reduzir o número de conexões usadas durante períodos sem uso de pico. Ao planejar tempos limite do lado do servidor, verifique se há uma estratégia de reciclagem ou pré-ping em uso para lidar com conexões obsoletas normalmente.
    Novo na versão 1.3.
    Veja também
    Usando FIFO vs. LIFO
    Lidando com desconexões
  • plugins  -
    lista de cadeias de nomes de plugins a serem carregados. Veja o CreateEnginePluginplano de fundo.
    Novo na versão 1.2.3.
  • strategy = 'plain'  -
    seleciona implementações alternativas de mecanismo. Atualmente disponíveis são:
  • executor = None  - uma função que recebe argumentos , para a qual a estratégia despacha toda a execução da instrução. Usado apenas por .(sql, *multiparams, **params)mockstrategy='mock'
sqlalchemy.engine_from_config( configuração , prefixo = 'sqlalchemy.' , ** kwargs ) 
Crie uma nova instância do mecanismo usando um dicionário de configuração.
O dicionário geralmente é produzido a partir de um arquivo de configuração.
As chaves de interesse engine_from_config()devem ser prefixadas, por exemplo sqlalchemy.url, sqlalchemy.echoetc. O argumento 'prefix' indica o prefixo a ser pesquisado. Cada chave correspondente (após a remoção do prefixo) é tratada como se fosse o argumento da palavra-chave correspondente a uma create_engine()chamada.
A única chave necessária é (assumindo o prefixo padrão) sqlalchemy.url, que fornece a URL do banco de dados .
Um conjunto selecionado de argumentos de palavra-chave será "coagido" ao tipo esperado com base nos valores da string. O conjunto de argumentos é extensível por dialeto usando o engine_config_typesacessador.
Parâmetros
  • configuration  - Um dicionário (normalmente produzido a partir de um arquivo de configuração, mas isso não é um requisito). Os itens cujas chaves começam com o valor de 'prefix' terão esse prefixo removido e serão passados ​​para create_engine .
  • prefixo  - Prefixo para corresponder e depois retirar as chaves da 'configuração'.
  • kwargs  - Cada argumento de palavra-chave engine_from_config()substitui o item correspondente retirado do dicionário 'configuração'. Os argumentos da palavra-chave não devem ser prefixados.
sqlalchemy.engine.url.make_url( nome_ou_url ) 
Dada uma instância de cadeia ou unicode, produza uma nova instância de URL.
A sequência especificada é analisada de acordo com as especificações da RFC 1738. Se um objeto de URL existente for passado, apenas retornará o objeto.
classe sqlalchemy.engine.url.URL( drivername , nome de usuário = nenhum , senha = nenhum , host = nenhum , porta = nenhum , banco de dados = nenhum , consulta = nenhum ) 
Representa os componentes de uma URL usada para conectar-se a um banco de dados.
Este objeto é adequado para ser passado diretamente para uma create_engine()chamada. Os campos da URL são analisados ​​de uma sequência pela make_url()função. o formato da string do URL é uma string no estilo RFC-1738.
Todos os parâmetros de inicialização estão disponíveis como atributos públicos.
Parâmetros
  • drivername  - o nome do back-end do banco de dados. Esse nome corresponderá a um módulo no sqlalchemy / database ou a um plug-in de terceiros.
  • nome de usuário  - O nome do usuário.
  • senha  - senha do banco de dados.
  • host  - O nome do host.
  • port  - O número da porta.
  • banco de dados  - O nome do banco de dados.
  • query  - Um dicionário de opções a serem passadas para o dialeto e / ou DBAPI na conexão.
get_dialect( ) 
Retorne a classe de dialeto do banco de dados SQLAlchemy correspondente ao nome do driver desta URL.
translate_connect_args( nomes = [] , ** kw ) 
Traduzir atributos de URL em um dicionário de argumentos de conexão.
Retorna atributos desse URL ( host , banco de dados , nome de usuário , senha , porta ) como um dicionário simples. Os nomes dos atributos são usados ​​como chaves por padrão. Atributos não definidos ou falsos são omitidos no dicionário final.
Parâmetros
  • ** kw  - Nomes de chave alternativos e opcionais para atributos de URL.
  • nomes  - Descontinuado. O mesmo objetivo que os nomes alternativos baseados em palavras-chave, mas correlaciona o nome ao original em termos posicionais.

Pooling 

Ele Enginesolicitará ao pool de conexões uma conexão quando os métodos connect()ou execute()forem chamados. O conjunto de conexões padrão,, QueuePoolabrirá conexões com o banco de dados conforme a necessidade. À medida que instruções simultâneas são executadas, QueuePoolseu pool de conexões aumentará para um tamanho padrão de cinco e permitirá um "estouro" padrão de dez. Como a base Engineé essencialmente a base do conjunto de conexões, você deve manter um único Enginepor banco de dados estabelecido em um aplicativo, em vez de criar um novo para cada conexão.
Nota
QueuePoolnão é usado por padrão para mecanismos SQLite. Consulte SQLite para obter detalhes sobre o uso do conjunto de conexões SQLite.
Para obter mais informações sobre o pool de conexões, consulte Pool de conexões .

Argumentos DBAPI customizados connect () 

Os argumentos personalizados usados ​​ao emitir a connect()chamada para o DBAPI subjacente podem ser emitidos de três maneiras distintas. Os argumentos baseados em string podem ser transmitidos diretamente da string da URL como argumentos de consulta:
db = create_engine('postgresql://scott:tiger@localhost/test?argument1=foo&argument2=bar')
Se o conector do banco de dados do SQLAlchemy estiver ciente de um argumento de consulta específico, ele poderá converter seu tipo de string para o tipo apropriado.
create_engine()também aceita um argumento connect_argsque é um dicionário adicional ao qual será passado connect(). Isso pode ser usado quando argumentos de um tipo diferente de string são necessários e o conector do banco de dados do SQLAlchemy não possui uma lógica de conversão de tipo presente para esse parâmetro:
db = create_engine('postgresql://scott:tiger@localhost/test', connect_args = {'argument1':17, 'argument2':'bar'})
O método de conexão mais personalizável de todas é passar um creator argumento, que especifica uma chamada que retorna uma conexão DBAPI:
def connect():
    return psycopg.connect(user='scott', host='localhost')

db = create_engine('postgresql://', creator=connect)

Configurando o Log 

O módulo de log padrão do Python é usado para implementar a saída de log informativo e de depuração com o SQLAlchemy. Isso permite que o log do SQLAlchemy se integre de maneira padrão a outros aplicativos e bibliotecas. Há também dois parâmetros create_engine.echoe create_engine.echo_pool presente em create_engine()que permitem o registo imediato a sys.stdout para fins de desenvolvimento local; esses parâmetros finalmente interagem com os criadores regulares de Python descritos abaixo.
Esta seção pressupõe familiaridade com o módulo de registro vinculado acima. Todo o log realizado pelo SQLAlchemy existe abaixo do sqlalchemy namespace, conforme usado por logging.getLogger('sqlalchemy'). Quando o log estiver configurado (ou seja, como via logging.basicConfig()), o espaço para nome geral dos registradores SA que podem ser ativados é o seguinte:
  • sqlalchemy.engine- controla eco ecoando. definido como logging.INFOpara saída da consulta SQL, logging.DEBUGpara consulta + saída do conjunto de resultados. Essas configurações são equivalentes echo=Truee echo="debug"ativadas create_engine.echo, respectivamente.
  • sqlalchemy.pool- controla o log do conjunto de conexões. definido para logging.INFOregistrar a invalidação da conexão e reciclar eventos; defina como logging.DEBUGpara registrar adicionalmente todos os check-ins e check-out de pool. Essas configurações são equivalentes pool_echo=Truee pool_echo="debug" ativadas create_engine.echo_pool, respectivamente.
  • sqlalchemy.dialects - controla o log personalizado para dialetos SQL, na medida em que o log é usado em dialetos específicos, o que geralmente é mínimo.
  • sqlalchemy.orm- controla o log de várias funções do ORM na medida em que o log é usado no ORM, o que geralmente é mínimo. Defina como logging.INFOpara registrar algumas informações de nível superior nas configurações do mapeador.
Por exemplo, para registrar consultas SQL usando o log do Python em vez do echo=Truesinalizador:
import logging

logging.basicConfig()
logging.getLogger('sqlalchemy.engine').setLevel(logging.INFO)
Por padrão, o nível de log é definido como logging.WARNdentro de todo o sqlalchemyespaço para nome, para que nenhuma operação de log ocorra, mesmo em um aplicativo que tenha o log ativado de outra forma.
Os echosinalizadores presentes como argumentos de palavra-chave para create_engine()e outros, bem como a echopropriedade Engineativada, quando configurada como True, tentarão primeiro garantir que o log esteja ativado. Infelizmente, o logging módulo não fornece nenhuma maneira de determinar se a saída já foi configurada (observe que estamos nos referindo se uma configuração de log foi configurada, não apenas que o nível de log está definido). Por esse motivo, qualquer echo=Truesinalizador resultará em uma chamada para o logging.basicConfig()uso de sys.stdout como destino. Ele também configura um formato padrão usando o nome do nível, o carimbo de data e hora e o nome do criador de logs. Observe que essa configuração tem o efeito de ser configurada , além de quaisquer configurações existentes do criador de logs. Portanto, ao usar o log do Python, verifique se todos os sinalizadores de eco estão definidos como False o tempo todo , para evitar linhas de log duplicadas.
O nome do criador de logs da instância, como um, Engine ou Poolusa como padrão uma cadeia de identificadores hexadecimais truncada. Para definir isso com um nome específico, use os argumentos das palavras-chave “logging_name” e “pool_logging_name” com sqlalchemy.create_engine().
Nota
O SQLAlchemy Engineconserva a sobrecarga da chamada de função Python emitindo apenas instruções de log quando o nível de log atual é detectado como logging.INFOou logging.DEBUG. Ele só verifica esse nível quando uma nova conexão é adquirida no pool de conexões. Portanto, ao alterar a configuração de log para um aplicativo já em execução, qualquer um Connectionque esteja ativo no momento ou, mais comumente, um Sessionobjeto que esteja ativo em uma transação, não registrará nenhum SQL de acordo com a nova configuração até que um novo Connection seja adquirido (no caso de Session, isso ocorre após o término da transação atual e o início de uma nova).

Postar um comentário

0 Comentários