Como logar em um banco diferente para cada usuário Django?

[Régis Silva]

Suponha que eu tenha um sistema Django num banco centralizado que faça o seguinte:
Para cada usuário logado ele se logue no seu próprio banco de dados, ou seja,
cada usuário tem seu banco, e quando ele se logar no sistema, o sistema automaticamente se conecta no seu banco.

Regis da Silva Web Developer

[Gilson Filho]

Você teria que trabalhar no formato de multi-tenant, fora que seria um esquema de configurações "on the fly", pq quando logar precisa carregar configurações de conexão do banco, relacionados ao usuário que logou.

Mas qual a necessidade disso?

--
Você recebeu essa mensagem porque está inscrito no grupo "Django Brasil" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para django-brasi...@googlegroups.com.
Para mais opções, acesse https://groups.google.com/d/optout.

[Eduardo Cuducos]

Oi Gilson,

Sobre a pergunta que fizesse para o Régis: tenho esse mesmo problema para lidar com um sistema legado (e tomo a liberdade de responder pois creio que o Régis está tentando resolver esse problema, desse projeto — estou junto com ele nessa de certa forma).

Enfm… o contexto é o seguinte: enquanto desenvolvemos uma nova aplicação que substituirá uma aplicação legada, ambas as aplicações tem que se conectar a um mesmo banco de dados (para o cliente poder ir usando a nova e dando feedback, mas tenha a legada para as funções ainda não implementadas na nova). E a arquitetura da aplicação legada impõe essas restrição:

www.servidor.com/joao ==> banco de dados: prefixo_joao

www.servidor.com/maria ==> banco de dados: prefixo_maria

Sacou?

A necessidade é temporária, enquanto a nova aplicação (que pode levar meses/anos) não chega a ponto de substituir totalmente a legada, temos que conversar com banco de dados arquitetado para a aplicação legada.

Faz sentido?

--
--
------------------------------------
Grupo Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
 
<*> Para visitar o site do grupo na web, acesse:
http://groups.google.com/group/python-brasil
 
<*> Para sair deste grupo, envie um e-mail para:
python-brasi...@googlegroups.com

---
Você recebeu essa mensagem porque está inscrito no grupo "Python Brasil" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para python-brasi...@googlegroups.com.

[Fabio C. Barrionuevo da Luz]

chutando... suponho que talvez uma solução maluca de Middleware (porque tem acesso a requisição) + Database Routers talvez funcione. 

https://docs.djangoproject.com/en/1.10/topics/db/multi-db/#database-routers

https://gist.github.com/ebugfix/7055ad6c5aed890ddc43 (não testei)

2016-10-26 16:39 GMT-03:00 Eduardo Cuducos <cud...@gmail.com>:

Oi Gilson,

Sobre a pergunta que fizesse para o Régis: tenho esse mesmo problema para lidar com um sistema legado (e tomo a liberdade de responder pois creio que o Régis está tentando resolver esse problema, desse projeto — estou junto com ele nessa de certa forma).

Enfm… o contexto é o seguinte: enquanto desenvolvemos uma nova aplicação que substituirá uma aplicação legada, ambas as aplicações tem que se conectar a um mesmo banco de dados (para o cliente poder ir usando a nova e dando feedback, mas tenha a legada para as funções ainda não implementadas na nova). E a arquitetura da aplicação legada impõe essas restrição:

www.servidor.com/joao ==> banco de dados: prefixo_joao

www.servidor.com/maria ==> banco de dados: prefixo_maria

Sacou?

A necessidade é temporária, enquanto a nova aplicação (que pode levar meses/anos) não chega a ponto de substituir totalmente a legada, temos que conversar com banco de dados arquitetado para a aplicação legada.

Faz sentido?

On Wed, Oct 26, 2016 at 5:33 PM Gilson Filho <m...@gilsondev.in> wrote:

Você teria que trabalhar no formato de multi-tenant, fora que seria um esquema de configurações "on the fly", pq quando logar precisa carregar configurações de conexão do banco, relacionados ao usuário que logou.

Mas qual a necessidade disso?

Em qua, 26 de out de 2016 às 17:29, Régis Silva <regis.sa...@gmail.com> escreveu:

Suponha que eu tenha um sistema Django num banco centralizado que faça o seguinte:
Para cada usuário logado ele se logue no seu próprio banco de dados, ou seja,
cada usuário tem seu banco, e quando ele se logar no sistema, o sistema automaticamente se conecta no seu banco.

Regis da Silva Web Developer

--

Você recebeu essa mensagem porque está inscrito no grupo "Django Brasil" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para django-brasil+unsubscribe@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--

--
------------------------------------
Grupo Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
 
<*> Para visitar o site do grupo na web, acesse:
http://groups.google.com/group/python-brasil
 
<*> Para sair deste grupo, envie um e-mail para:

python-brasil+unsubscribe@googlegroups.com

---
Você recebeu essa mensagem porque está inscrito no grupo "Python Brasil" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para python-brasil+unsubscribe@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--
--
------------------------------------
Grupo Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
 
<*> Para visitar o site do grupo na web, acesse:
http://groups.google.com/group/python-brasil
 
<*> Para sair deste grupo, envie um e-mail para:

python-brasil+unsubscribe@googlegroups.com

---
Você recebeu essa mensagem porque está inscrito no grupo "Python Brasil" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para python-brasil+unsubscribe@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--

Fábio C. Barrionuevo da Luz
Palmas - Tocantins - Brasil - América do Sul

http://pythonclub.com.br/

Blog colaborativo sobre Python e tecnologias Relacionadas, mantido totalmente no https://github.com/pythonclub/pythonclub.github.io .

Todos são livres para publicar. É só fazer fork, escrever sua postagem e mandar o pull-request. Leia mais sobre como publicar em README.md e contributing.md.

Regra básica de postagem:

"Você" acha interessante? É útil para "você"? Pode ser utilizado com Python ou é útil para quem usa Python? Está esperando o que? Publica logo, que estou louco para ler...

[Avraham Serour]

Nào faz sentido para mim não.

Você pode ter duas aplicações acessando o mesmo banco de dados, legada e nova, ou até mesmo uma terceira que faz café.

Funções novas podem ser feitas na aplicação e o banco de dados não tem nada a ver com isso.

Se você precisar armazenar coisas novas você ainda assim não precisa de um banco separada por causa disso, você pode adicionar tabelas no mesmo banco e que só o sistema novo use, o sistema legado não precisa saber que tem tabelas novas.

Você pode ir desenvolvendo o sistema novo e ir adicionando tabelas, só tome cuidado em não alterar o nome de tabelas ou colunas ou apagar tabelas ou colunas que o sistema antigo use.

Avraham

2016-10-26 22:39 GMT+03:00 Eduardo Cuducos <cud...@gmail.com>:

Oi Gilson,

Sobre a pergunta que fizesse para o Régis: tenho esse mesmo problema para lidar com um sistema legado (e tomo a liberdade de responder pois creio que o Régis está tentando resolver esse problema, desse projeto — estou junto com ele nessa de certa forma).

Enfm… o contexto é o seguinte: enquanto desenvolvemos uma nova aplicação que substituirá uma aplicação legada, ambas as aplicações tem que se conectar a um mesmo banco de dados (para o cliente poder ir usando a nova e dando feedback, mas tenha a legada para as funções ainda não implementadas na nova). E a arquitetura da aplicação legada impõe essas restrição:

www.servidor.com/joao ==> banco de dados: prefixo_joao

www.servidor.com/maria ==> banco de dados: prefixo_maria

Sacou?

A necessidade é temporária, enquanto a nova aplicação (que pode levar meses/anos) não chega a ponto de substituir totalmente a legada, temos que conversar com banco de dados arquitetado para a aplicação legada.

Faz sentido?

On Wed, Oct 26, 2016 at 5:33 PM Gilson Filho <m...@gilsondev.in> wrote:

Você teria que trabalhar no formato de multi-tenant, fora que seria um esquema de configurações "on the fly", pq quando logar precisa carregar configurações de conexão do banco, relacionados ao usuário que logou.

Mas qual a necessidade disso?

Em qua, 26 de out de 2016 às 17:29, Régis Silva <regis.sa...@gmail.com> escreveu:

Suponha que eu tenha um sistema Django num banco centralizado que faça o seguinte:
Para cada usuário logado ele se logue no seu próprio banco de dados, ou seja,
cada usuário tem seu banco, e quando ele se logar no sistema, o sistema automaticamente se conecta no seu banco.

Regis da Silva Web Developer

--

Você recebeu essa mensagem porque está inscrito no grupo "Django Brasil" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para django-brasil+unsubscribe@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--

--
------------------------------------
Grupo Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
 
<*> Para visitar o site do grupo na web, acesse:
http://groups.google.com/group/python-brasil
 
<*> Para sair deste grupo, envie um e-mail para:

python-brasil+unsubscribe@googlegroups.com

---
Você recebeu essa mensagem porque está inscrito no grupo "Python Brasil" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para python-brasil+unsubscribe@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--
--
------------------------------------
Grupo Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
 
<*> Para visitar o site do grupo na web, acesse:
http://groups.google.com/group/python-brasil
 
<*> Para sair deste grupo, envie um e-mail para:

python-brasil+unsubscribe@googlegroups.com

---
Você recebeu essa mensagem porque está inscrito no grupo "Python Brasil" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para python-brasil+unsubscribe@googlegroups.com.

[Bruno Rocha]

Pode criar um MIddleware mas primeiro teria que ter seu banco de dados de login separado, pois terá que acessar algum banco de dados para que o usuário possa fazer login e só depois poderá fazer o switch de database, acredito que o middleware funcione apensa se pude isolar o banco de usuarios.

class TenantMiddleware(object):

    def process_request(self, request):

        if request.user.username == "regis":

            settings.DATABASE = {.....}

        else:

            settings.DATABASE = { other ...}

--

Bruno Rocha - @rochacbruno

http://brunorocha.org

http://github.com/rochacbruno

http://linkedin.com/in/rochacbruno
http://plus.google.com/+BrunoRocha1 

[Eduardo Cuducos]

Avraham, gostei da tua resposta : )

Vamos supor que o que a aplicação entrega para o usuário é uma to do list. 

Tem uma aplicação legada onde o usuário pode ver as tarefas, marcar tarefas como feitas, e adicionar novas tarefas. E uma aplicação nova, em desenvolvimento, que por enquanto só possibilita que o usuário veja as tarefas e as marque como feitas (a opção de adicionar ainda não foi implementada).

Os dados que o usuário vê acessando a URL da aplicação legada tem que ser os mesmos dados que ele vê acessando a URL da aplicação nova. Ou seja, se em www.servidor.com/joao ele vê “Comprar pão”, em beta.servidor.com/joao ele vê “Comprar pão” também.

Se ele adicionar “Comprar banana” em www.servidor.com/joao, em beta.servidor.com/joao “Comprar banana” tem que aparecer também.

Sinceramente não sei como fazer isso sem acessar o mesmo banco de dados (ou sem usar algo mais complexo, como ficar replicando os dados em dois bancos com estruturas distintas).

Como você resolveria esse problema? Pode nos dar umas pistas — quero que não faça sentido para mim também usar o mesmo banco de dados hehe…

Muito obrigado,

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para django-brasi...@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--

--
------------------------------------
Grupo Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
 
<*> Para visitar o site do grupo na web, acesse:
http://groups.google.com/group/python-brasil
 
<*> Para sair deste grupo, envie um e-mail para:

python-brasi...@googlegroups.com

---
Você recebeu essa mensagem porque está inscrito no grupo "Python Brasil" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para python-brasi...@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--
--
------------------------------------
Grupo Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
 
<*> Para visitar o site do grupo na web, acesse:
http://groups.google.com/group/python-brasil
 
<*> Para sair deste grupo, envie um e-mail para:

python-brasi...@googlegroups.com

---
Você recebeu essa mensagem porque está inscrito no grupo "Python Brasil" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para python-brasi...@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--
--
------------------------------------
Grupo Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
 
<*> Para visitar o site do grupo na web, acesse:
http://groups.google.com/group/python-brasil
 
<*> Para sair deste grupo, envie um e-mail para:

python-brasi...@googlegroups.com

---
Você recebeu essa mensagem porque está inscrito no grupo "Python Brasil" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para python-brasi...@googlegroups.com.

[Avraham Serour]

Eu quis dizer exatamente que você pode ter um banco de dados só, com as duas ou ate mesmo tres aplicacoes acessando o mesmo banco de dados.

A minha pergunta é se você tem algum motivo que te força a usar bancos diferentes.

Avraham

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para django-brasil+unsubscribe@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--

--
------------------------------------
Grupo Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
 
<*> Para visitar o site do grupo na web, acesse:
http://groups.google.com/group/python-brasil
 
<*> Para sair deste grupo, envie um e-mail para:

python-brasil+unsubscribe@googlegroups.com

---
Você recebeu essa mensagem porque está inscrito no grupo "Python Brasil" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para python-brasil+unsubscribe@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--
--
------------------------------------
Grupo Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
 
<*> Para visitar o site do grupo na web, acesse:
http://groups.google.com/group/python-brasil
 
<*> Para sair deste grupo, envie um e-mail para:

python-brasil+unsubscribe@googlegroups.com

---
Você recebeu essa mensagem porque está inscrito no grupo "Python Brasil" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para python-brasil+unsubscribe@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--
--
------------------------------------
Grupo Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
 
<*> Para visitar o site do grupo na web, acesse:
http://groups.google.com/group/python-brasil
 
<*> Para sair deste grupo, envie um e-mail para:

python-brasil+unsubscribe@googlegroups.com

---
Você recebeu essa mensagem porque está inscrito no grupo "Python Brasil" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para python-brasil+unsubscribe@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--
--
------------------------------------
Grupo Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
 
<*> Para visitar o site do grupo na web, acesse:
http://groups.google.com/group/python-brasil
 
<*> Para sair deste grupo, envie um e-mail para:

python-brasil+unsubscribe@googlegroups.com

---
Você recebeu essa mensagem porque está inscrito no grupo "Python Brasil" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para python-brasil+unsubscribe@googlegroups.com.

[Eduardo Cuducos]

Muito legal a solução, Bruno — muito obrigado.

Acho que criar um novo banco de dados para controlar os logins é viável, é uma boa solução. Tá com cara de que vai funcionar — faz sentido, Régis?

Massa, valeuzão ; )

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para django-brasi...@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--

--
------------------------------------
Grupo Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
 
<*> Para visitar o site do grupo na web, acesse:
http://groups.google.com/group/python-brasil
 
<*> Para sair deste grupo, envie um e-mail para:

python-brasi...@googlegroups.com

---
Você recebeu essa mensagem porque está inscrito no grupo "Python Brasil" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para python-brasi...@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--
--
------------------------------------
Grupo Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
 
<*> Para visitar o site do grupo na web, acesse:
http://groups.google.com/group/python-brasil
 
<*> Para sair deste grupo, envie um e-mail para:

python-brasi...@googlegroups.com

---
Você recebeu essa mensagem porque está inscrito no grupo "Python Brasil" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para python-brasi...@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--
--
------------------------------------
Grupo Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
 
<*> Para visitar o site do grupo na web, acesse:
http://groups.google.com/group/python-brasil
 
<*> Para sair deste grupo, envie um e-mail para:

python-brasi...@googlegroups.com

---
Você recebeu essa mensagem porque está inscrito no grupo "Python Brasil" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para python-brasi...@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--

Bruno Rocha - @rochacbruno

http://brunorocha.org

http://github.com/rochacbruno

http://linkedin.com/in/rochacbruno
http://plus.google.com/+BrunoRocha1 

--
--
------------------------------------
Grupo Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
 
<*> Para visitar o site do grupo na web, acesse:
http://groups.google.com/group/python-brasil
 
<*> Para sair deste grupo, envie um e-mail para:

python-brasi...@googlegroups.com

---
Você recebeu essa mensagem porque está inscrito no grupo "Python Brasil" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para python-brasi...@googlegroups.com.

[Marcelo Theodoro]

Espero não parecer pedante aqui, mas existe um certo pré-conceito que eu tenho aplicado em mim mesmo e tenho tido bons resultados, que é: Se a solução que pensei para um problema for muito distópica do que é considerado óbvio, eu provavelmente estou olhando para o problema da perspectiva errada.

Acredito que este pode ser o caso do OP. Obviamente, eu posso estar completamente errado e o OP pode estar pensando numa solução completamente inovadora e "fora da caixa", mas apenas com as informações apresentadas, não tem como ter certeza.

OP, dê mais detalhes sobre o domínio do problema, que podem surgir sugestões melhores.

Agora, caso você realmente queira fazer dessa maneira: Como está sendo feita a autenticação do usuário? Se você estiver usando a ORM do Django para fazer a autenticação, pode ter problemas se simplesmente alterar a base de dados padrão do projeto. Mas desconsiderando a autenticação e eventualmente efeitos colaterais dessa ação, utilizar um middleware como o Bruno citou provavelmente vai fazer isso acontecer.

[Eduardo Cuducos]

Muito obrigado mais uma vez Avraham e Marcelo!

Sobre a pergunta do Avraham:

> A minha pergunta é se você tem algum motivo que te força a usar bancos diferentes.

O motivo é: arquitetura da aplicação legada. Ela que é feita assim, com esses bancos diferentes por usuário.

Essa aplicação legada está largada há uns 8 anos sem manutenção alguma, quem a criou já saiu da empresa etc. Ela é uma joça macarrônica (sim, tem SQL na view; sim, tem JavaScript inline em cada HTML; e por aí vai), e sem nenhum teste. A ideia é que a nova aplicação (que não começamos a desenvolver) supra o technical debt dela, para que melhorias possam ser concebíveis no futuro.

E sobre a pergunta do Marcelo:

> OP, dê mais detalhes sobre o domínio do problema, que podem surgir sugestões melhores.

Não sou o OP, mas estou com ele no mesmo projeto. Então assumo que meus dos emails anteriores eram um pouco desse contexto. A autenticação hoje (na aplicação legada) é feita assim (a nova não existe ainda, estamos pensando em como estruturá-la ainda):

1. Cada usuário acessa pelo path dele (João acessa em www.servidor.com/joao e Maria acessa em www.servidor.com/maria) — isso foi feito assim, creio eu, pois os clientes de cada usuário acessam a aplicação pela URL do usuário (por exemplo, se você usa a aplicação por ser cliente do João, você vai fazer login, com seu próprio usuário e senha em www.servidor.com/joao, e se tentar no /maria não vai funcionar). 
   
2. O servidor busca login e senha no banco de dados de cada um de acordo com a URL (/joao informa ao servidor que é para autenticar com o banco prefixo_joao e /maria, com o banco prefixo_maria).

Não estou falando que tinha que ser feito assim, claro. Apenas que é assim que foi feito ; )

Ajudei?

Muito obrigado,

--

[José Luis Segatto Junior]

Bom dia,

Eu infelizmente não tenho uma solução para o problema, mas eu achei curioso os questionamentos quanto a forma de fazer (acessar bancos diferentes de acordo com o login).

Suponhamos o seguinte problema: você vai desenvolver um sistema que rodará em servidores controlados pela sua empresa, e que será acessado por empresas clientes diferentes. Alguém consegue pensar numa solução melhor do que fazer um banco separado pra cada cliente? Os bancos poderiam estar em servidores separados, ter uma rotina de backup diferente pela qual o cliente pagaria diferenciado...

​
Régis e Eduardo, desculpem o quase sequestro da thread.

zé

[Avraham Serour]

Que bagunça :(, meus pêsames

Isso é meio problemático por cause de coisas como o middleware de gerenciamento de sessão, que vai usar o database antes mesmo de chegar na sua view.

Você poderia ter varias locations no nginx, cada uma apontando para uma aplicação diferente, que na pratica seria a mesma aplicação mas configurada com default database diferentes. Isso pode ser um problema se você tiver muitos clientes, vai comer muita memoria.

Ou você pode usar algum desses middlewares para fazer o routing de DB pelo request, tome cuidado para ele ser o primeiro.

Eu dei uma olhada em algumas soluções na internet e não gostei muito do código, principalmente pelo uso de variáveis globais, se alguém achar alguma coisa melhor posta aí.

Eu vi umas soluções de usar o using em cada model, eu não gostei disso porque alem do trabalho de trocar o uso em cada model e o risco de não lembrar não ajuda se você usar algum app externo, se você tiver uma dependencia ela vai usar o banco default.

Eu ia escrever uma terceira alternativa usando o views no banco ou FDW, mas comecei a repensar se esta é realmente uma boa ideia.

Você tem que usar o mesmo path das coisas com a aplicação nova?

Do jeito que está um usuário não vai conseguir logar em dois bancos ao mesmo tempo apesar de ser o mesmo sistema, o cookie de sessionid é armazenado pelo domínio, então quando eu acessar servidor.com/joao e logar, o meu browser vai ter um cookie sessionid com valor 123, depois se eu acessar servidor.com/maria a aplicação vai no db maria na tabela de session e ver que não tem session 123, e ai vai determinar que o usuário não está logado.

Quando eu logar agora eu vou receber um outro sessionid com valor 567 por exemplo

E quando eu voltar para servidor.com/joao vou estar deslogado.

Isso pode gerar problemas para qualquer coisa armazenada em cookies como language.

Você pode em vez de usar servidor.com/cliente usar subdominios? tipo cliente.servidor.com, desse jeito vão ter cookies separados.

Você pode anotar isso por enquanto como known issue.

Você pode ter um terceiro banco central para gerenciar coisas em comum entre os clientes, tipo session e talvez auth.

No futuro cada cliente vai continuar com bancos separados ou todos vão usar o mesmo banco? Do ponto de vista de negocio eu acho que faz sentido cada cliente ter um banco separado, eu só mudaria para cada cliente ter o seu próprio domínio ou subdomínio, desse jeito você poderia trocar um cliente de servidor sem ninguém perceber, de repente o cliente pagou mais e quer um servidor dedicado por exemplo.

Ter bancos separados pode facilitar em coisas como backup e restore, um cliente te liga e pede para mandar o dump dos dados dele de ontem, outro paga para ter backup duas vezes por dia ou retenção de 30 dias sei lá.

Você ainda pode usar isso para marketing como uma coisa de segurança, de que cada cliente tem um banco de dados separado, isolado, se D's me livre acontecer alguma coisa, os dados de cada cliente estão compartimentalizados etc.

Boa sorte

Avraham

python-brasil+unsubscribe@googlegroups.com

---
Você recebeu essa mensagem porque está inscrito no grupo "Python Brasil" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para python-brasil+unsubscribe@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--

--
------------------------------------
Grupo Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
 
<*> Para visitar o site do grupo na web, acesse:
http://groups.google.com/group/python-brasil
 
<*> Para sair deste grupo, envie um e-mail para:

python-brasil+unsubscribe@googlegroups.com

---
Você recebeu essa mensagem porque está inscrito no grupo "Python Brasil" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para python-brasil+unsubscribe@googlegroups.com.

[José Luis Segatto Junior]

Avraham,

Muito obrigado pela prontidão e preocupação.

Talvez eu não tenha deixado claro que se trata de uma situação hipotética, embora plenamente possível IMHO.

Eu só coloquei ela aqui porque me pareceu estranho os questionamentos quanto à solução "acessar banco diferente de acordo com o login".

zé

[Eduardo Leones]

Pessoal, bom dia.

Aproveitando a deixa, e já encaixando outra dúvida que tem haver com o tópico. Eu trabalhei numa empresa alguns anos atrás que tinha uma aplicação web em PHP que usava duas conexões de banco de dados. A conexão master para aplicação em si e uma outra conexão com um servidor replicado da primeira, porém, essa segunda apenas com a função de gerar os relatórios.

É possível fazer algo do tipo com Django?

Eduardo

--
Você recebeu essa mensagem porque está inscrito no grupo "Django Brasil" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para django-brasil+unsubscribe@googlegroups.com.

[Eduardo Cuducos]

Avraham, mais uma vez, muito obrigado!

Seu email oferece ideias sensacionais. Rotear pelo location do nginx acho que é a melhor solução que já vi até agora — até pq não teremos clientes novos enquanto não matarmos a aplicação legada (impossível de escalar do jeito que está).

A preocupação com cookies também é muito válida, mas já pensava em comunicar o cliente dos problemas sobre esses pontos, avisando que se trata de um situação transitória.

Por fim subdomínios podem ser uma boa mesmo para a nova aplicação. Para a antiga não tem quem implemente… então não colocaria como prioridade.

José Luis, tu não sequestrou a thread não — foi super pertinente tua dúvida.

Eduardo, pelo o que eu entendi da tua pergunta, isso rola no Django sim — mas confesso que nunca usei.

Muito obrigado,

Eduardo Cuducos

http://cuducos.me/

python-brasi...@googlegroups.com

---
Você recebeu essa mensagem porque está inscrito no grupo "Python Brasil" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para python-brasi...@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--
--
------------------------------------
Grupo Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
 
<*> Para visitar o site do grupo na web, acesse:
http://groups.google.com/group/python-brasil
 
<*> Para sair deste grupo, envie um e-mail para:

python-brasi...@googlegroups.com

---
Você recebeu essa mensagem porque está inscrito no grupo "Python Brasil" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para python-brasi...@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--
--
------------------------------------
Grupo Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
 
<*> Para visitar o site do grupo na web, acesse:
http://groups.google.com/group/python-brasil
 
<*> Para sair deste grupo, envie um e-mail para:

python-brasi...@googlegroups.com

---
Você recebeu essa mensagem porque está inscrito no grupo "Python Brasil" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para python-brasi...@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--
--
------------------------------------
Grupo Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
 
<*> Para visitar o site do grupo na web, acesse:
http://groups.google.com/group/python-brasil
 
<*> Para sair deste grupo, envie um e-mail para:

python-brasi...@googlegroups.com

---
Você recebeu essa mensagem porque está inscrito no grupo "Python Brasil" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para python-brasi...@googlegroups.com.

[flit]

Vindo da parte de infra eu pessoalmente iria para:

"Seu email oferece ideias sensacionais. Rotear pelo location do nginx acho que é a melhor solução que já vi até agora — até pq não teremos clientes novos enquanto não matarmos a aplicação legada (impossível de escalar do jeito que está)."

--> Eu prefiro isolar os clientes e bancos. Por razões de isolamento, diferença de carga e dados, Compliance e performance. E claro isso me permite por exemplo alocar DBs otimizados. No caso usando aws RDS poderia usar uma Micro para um cliente pequeno e uma media para outro cliente. Ou ate mesmo em ZONAS diferentes. Menor latencia usa a zona SA (Sao Paulo) mas é mais cara tb. Menor custo? Oregon.

"A preocupação com cookies também é muito válida, mas já pensava em comunicar o cliente dos problemas sobre esses pontos, avisando que se trata de um situação transitória.

Por fim subdomínios podem ser uma boa mesmo para a nova aplicação. Para a antiga não tem quem implemente… então não colocaria como prioridade."

A melhor questão dos SUBdominios ao invés de /cliente1, /cliente2/ é que vc pode fazer balanceamento de carga por DNS direto (route53, cloudflare,cdns,etc). Usando /cliente1 e /cliente2 obrigatoriamente vc vai ter que ter um proxy roteando o que torna a infra um pouco mais complicada. (Haproxy e outros).

[]s

Henrique

[Gilson Filho]

Possível sim. Na documentação explica com configurar isso:

https://docs.djangoproject.com/en/1.10/topics/db/multi-db/

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para django-brasi...@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--
Você recebeu essa mensagem porque está inscrito no grupo "Django Brasil" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para django-brasi...@googlegroups.com.

[Nando Florestan]

Evite desenvolver uma aplicação nova (que certamente terá bugs) usando os mesmos dados de uma aplicação velha. Fazer isso é não dar valor algum aos dados existentes. Face a um problema que venha a acontecer, qual das duas aplicações é a responsável?

Como o OP não parece *desejar* essa arquitetura de múltiplos bancos, seria o caso de aproveitar o surgimento da nova aplicação para resolver esse "problema", ao invés de perpetuá-lo.

A entrega da aplicação nova poderia ser feita gradualmente. Hoje você migra os usuários Adão e Belmiro para o banco de dados consolidado e para o uso da app nova; amanhã outros usuários.

Dito isso, a arquitetura de multi-tenancy usando múltiplos bancos de dados apresenta as seguintes...

Desvantagens:

- Quando você altera tabelas, tem que rodar a migração em muitos bancos, o que é muito demorado. Qual é o momento certo de começar a executar o código novo?
- Gerenciamento. Você tem muitos bancos para migrar, para fazer backup, para perder sem perceber etc.
- Você não é o Facebook, então não deveria lidar com complexidades que só o Facebook lida. Essa arquitetura é mais complexa do que ter um banco só. Provavelmente é desnecessária para você. E você poderia fazer o sharding no futuro, quando precisasse, ao invés de agora.
- A "user affinity" com um certo banco de dados pode levar a problemas inesperados. Por exemplo, como isso afeta o número de conexões que a sua aplicação terá de abrir? Fica melhor ou fica pior? (Numa aplicação "normalzinha" geralmente se tem um pool de umas 30 a 150 conexões, que ao invés de serem fechadas a cada uso, são reutilizadas pela aplicação, mas são fechadas depois de um tempo sem uso.)
- Performance. A cada request você consulta dois bancos de dados ao invés de um só.

Vantagens:

- Caso a aplicação tenha um sucesso Faceboomenal, a sua arquitetura já está com o sharding feito; não será difícil crescer, contanto que seja sempre fácil descobrir qual servidor é o que atende determinado cliente.
- Você consegue distribuir seus clientes pelas máquinas usando o critério que quiser.
- Teus IDs podem ser inteiros comuns, que mesmo assim nunca vão estourar.
- Performance. Os índices das tabelas são muito mais curtos.
- Segurança: menos chance de um bug crasso permitir que um usuário veja os dados de outro.

Eu já criei uma aplicação com essa arquitetura no passado. (Não a do OP, outra aplicação, hehehe.) Fiz com confiança porque naquela aplicação era claro que nenhum usuário jamais desejaria ver os dados de outro. Não foi nem um pouco difícil fazer isso funcionar, usando Pyramid, sem nenhum middleware, e sem alterar as URLs nem os domínios. Eu buscava a entidade do usuário logado, e esse model tinha uma propriedade, que retornava uma sessão do SQLAlchemy para acessar o banco de dados pessoal.

Sabe o que aconteceu? A aplicação ficou pouquíssimo tempo em produção, por outras razões não relacionadas. Acho que podemos concordar que foi completamente inútil lidar com essa questão se eu tive poucos usuários.

Atualmente toco uma aplicação que certamente terá muitos usuários em breve, mas pretendo só fazer sharding quando for necessário.

[Eduardo Cuducos]

Nando,

Pontos fortes esses de não fazer aplicações acessarem o mesmo banco de dados, muito obrigado. Entretanto dado que o contexto é de uma aplicação de tamanho razoavelmente grande, e que a empresa não tem quem dê manutenção na legada, nem um time grande para tocar o desenvolvimento da nova, não acho que seja a melhor estratégia desenvolver uma nova aplicação desacoplada dos dados da legada.

Até a nova aplicação crescer a ponto de podermos migrar alguns usuários (ou seja, que o mínimo das funções seja refeita) muito tempo já se passou (lembra que a aplicação é grande e a equipe pequena), esses usuários que existem hoje (insatisfeitos pois a aplicação legada está caindo aos pedaços e não tem mais suporte) já não serão mais clientes, já terão rescindido contrato e ido embora.

Por isso pensei no desenvolvimento em paralelo ao banco de dados antigo. A equação é: x meses/anos desenvolvendo uma coisa e arriscar perder todos os clientes no caminho, ou arriscar ter um banco de dados tomando paulada de dois lados enquanto gradualmente uma vai crescendo? Achei que valeria a pena não perder os clientes…

Sobre as desvantagens: migrações não vão ocorrer até que a aplicação legada seja fechada (senão quebramos a legada). Gerenciamento tende a zero pelo mesmo motivo, estruturalmente o banco vai ficar intacto até que a aplicação nova substitua a legada. Performance é o preço a se pagar pela estratégia que descrevi anteriormente (mas mesmo assim acredito que o Django multi tenant vai ter performance melhor do que esse Code Igniter macarrônico, cheio de AJAX inline e SQL nas views). Por fim a complexidade realmente não é necessária, mas é herdada — e pretendemos assumi-la apenas em caráter de transição.

Faz sentido assim ou continua sendo uma insanidade na tua opinião? Não quero ficar antagonizando aqui. Mas o foco realmente é na estratégia (no sentido amplo, envolvendo a parte financeira e tecnológica), então trouxe mais contexto para ver se mesmo assim tu acha loucura o estratégia que, a princípio, motivou a pergunta do Régis (OP).

Muito obrigado,

--

--
------------------------------------
Grupo Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
 
<*> Para visitar o site do grupo na web, acesse:
http://groups.google.com/group/python-brasil
 
<*> Para sair deste grupo, envie um e-mail para:
python-brasi...@googlegroups.com

---

Você recebeu essa mensagem porque está inscrito no grupo "Python Brasil" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para python-brasi...@googlegroups.com.

[Nando Florestan]

Eduardo,

Entendi. Mas então precisa prestar muita atenção à qualidade nesse projeto. Não deixa de fazer code review em tudo... e testes até ficar boring.

[Fred Chevitarese]

Opa! 

Achei a thread bem interessante, li quase todos os emails :P 

Vou contar da experiência que tive com algo parecido. 

Eu fiquei encarregado de um sistema de troca de informações de saúde que foi escrito em ASP. 

Era duro de continuar mexendo nele, daí resolvi migrar para Django. 

Mas a aplicação tinha N clientes, não podia parar.

O que fiz... 

Fiz o que alguém falou acima... Fui adicionando minhas funcionalidades ao novo sistema e migrando aos poucos... O sistema velho não precisava saber das novas tabelas ;) 

Por exemplo: 

A parte das transações foi refeita... Então, eu salvava na tabela antiga (enquanto não ficava pronta o esquema novo) e na nova, porque já ia testando, mostrando pro cliente etc... 

Quando ficava do jeito que ele queria, eu simplesmente passava à usar só o recurso novo. 

Foi trampo d+, mas essa mudança foi gradual... Não sei se eu não entendi bem, mas tinha uma leve diferença. De fato, cada cliente tinha seu banco de dados separado, seu servidor separado, então nesse ponto foi tranks. 

E a situação foi assim também... Sistema grande, time pequeno... Era só eu kkkkkkkkkkk

"

São os homens que mais me surpreendem na humanidade. Porque perdem a saúde para juntar dinheiro, depois perdem dinheiro para recuperar a saúde. E por pensarem ansiosamente no futuro, esquecem do presente de tal forma que acabam por não viver nem o presente nem o futuro. E vivem como se nunca fossem morrer e morrem como se nunca tivessem vivido” - Dalai Lama.

"

Fred Chevitarese - GNU/Linux

http://chevitarese.wordpress.com

python-brasil+unsubscribe@googlegroups.com

---
Você recebeu essa mensagem porque está inscrito no grupo "Python Brasil" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para python-brasil+unsubscribe@googlegroups.com.

[Eduardo Cuducos]

Nando, mas uma vez obrigado por compartilhar tua experiência — e, principalmente por doar teu tempo para ponderar os pormenores do contexto aqui!

Fred: digo o mesmo, meu caro!

Muito obrigado,