Migração dados 1.5 para 2.0

Vera

@rarandrade
obrigada! Vi que são 30 tabelas.

@rogeriolino
devemos ter algum cuidado especial ao comparar estrutura MySQL com PostgreSQL?
Já existe um manual ou um local onde seja possível conhecer as telas / funcionalidades da versão 2.0? Não localizei esta informação no http://novosga.org/docs/current/

Vi que tem uma tabela 'agendamentos', estou interessada em conhecer este item, pois uma de nossas unidades tem esta necessidade e isto pode significar agilizar nossa migração para a versão 2.0...

rogeriolino

Vera não precisa se preocupar com banco. Fazendo o script para um será fácil adaptar para o outro.

A documentação da v2.0 ainda está bem limitada.

Essa tabela agendamentos serve para integrar com algum sistema de agendamento, caso possua. É possível vincular o atendimento gerado a um registro nessa tabela.

Vera

@rogeriolino
apesar de não conhecer as telas da versão 2.0, tentei fazer uma análise inicial usando como referência apenas os nomes das tabelas. Você pode validar ou enviar um link onde eu possa obter mais informações?

Coloquei ??? nas tabelas em que estou com dúvidas.

Não localizei uma tabela da versão 2.0 equivalente à tabela oauth_scopes da versão 1.5.1.
Por acaso as tabelas 'oauth' são as que contém os dados de integração com outras aplicações via API web do sistema? Como na Prefeitura não usamos, nossas tabelas estão vazias. Imagino que neste caso estas tabelas também não seriam migradas, bastaria fazer a configuração pela aplicação.

Aguardo a revisão desta etapa de identificação das tabelas para poder iniciar a parte de análise dos campos.

Obrigada.

Os dados abaixo possuem tabulações, se quiser uma tabela formatada, copie e no Excel use a opção 'colar especial / texto'.

Tabela versão 2.0 = Tabela versão 1.5.1
agendamentos = NOVA
atendimentos = atendimentos
atendimentos_codificados = atend_codif
atendimentos_metadata = atend_meta
clientes = NOVA - CLIENTES AGENDADOS???
contador = contador
departamentos = grupos ???
historico_atendimentos = historico_atendimentos
historico_atendimentos_codificados = historico_atend_codif
historico_atendimentos_metadata = historico_atend_meta
locais = locais
lotacoes = usu_grup_cargo + cargos_mod_perm???
metadata = NOVA - config + modulos???
migration_versions = NOVA - QUAL FINALIDADE???
oauth_access_tokens = oauth_access_tokens
oauth_clients = oauth_clients
oauth_refresh_tokens = oauth_refresh_tokens
??? = oauth_scopes
paineis = paineis
paineis_servicos = paineis_servicos
painel_senha = painel_senha
perfis = cargos
prioridades = prioridades
servicos = servicos
servicos_metadata = serv_meta
servicos_unidades = uni_serv
servicos_usuarios = usu_serv
unidades = unidades
unidades_metadata = uni_meta
usuarios = usuarios
usuarios_metadata = usu_meta

rogeriolino

Vera

As tabelas OAuth não precisa migrar.

Clientes é a tabela para guardar os dados dos clientes que antes eram salvos direto na tabela de atendimentos. Agora ao invés de replicar os dados, faz a associação. Assim também é possível fazer integrações e relatórios.

Departamentos é uma nova entidade utilizada para agrupar serviços. É útil na triagem-touch. E para futuros relatórios.

Metadata seria a antiga tabela config. São metadados globais do sistema.

A tabela migration_versions é de controle do Doctrine Migrations, serve para controlar a execução dos scripts de migração para futuros upgrades.

rarandrade

@rogeriolino

Vc chegou a testar o painel web usando o sistema com banco Postgres, eu não consigo fazer rodar o painel de jeito nenhum cadastro dentro de WEB API client ele gera o public_id e o Client Secret, mas quando insiro essas chaves no painel aparece sempre a mesma msg

"Oops!
Bad Request: The client credentials are invalid"

E se executo o Force reload aparece essa msg

"Oops!
Unauthorized: The access token provided is invalid."

Dependo de fazer o funcionar o painel para conseguir testar bem o sistema para tentar ajudar na migração dos dados

rarandrade

@rogeriolino

Problema do Painel resolvido

rogeriolino

rarandrade Não cheguei testar não. Era algum problema do sistema?

ayrton

rarandrade estou com o problema do painel do sga 2.4 no Windows não estou conseguindo configurar poderia me ajuda ? os mesmos erros que estava acontecendo com você estão comigo.

Vera

@rogeriolino voltei das férias e vou retomar os estudos da migração, obrigada pelas orientações.

Joceiltongomes2210

@rogeriolino você tem o sga 2.0 com as dependencias instalado amigo, pode liberar pra nos amigo porque não estou conseguindo instalar ele pode liberar pra nos amigo NOVOSGA 2.O FINAL

GilsonCouto

Boa tarde! Alguém já criou um script para migração dos dados?

rarandrade

ayrton Desculpe a demora para responder, verifique se não esta com espaço no final do client_secret e no public_id, não sei por que no momento que eu esta copiando os dados eles esta copiando um espaço no final.

marcelodalmeida

É possivel atualizar da versão v.1.1.4 para v2.0.8 ?

Vera

Olá, apenas atualizando...
Há alguns meses passamos a copiar diariamente os dados do NovoSGA para o banco de dados de um sistema interno de BI onde são feitos relatórios e gráficos de análises mais detalhados do que os oferecidos pelo NovoSGA.
Continuamos a usar a versão 1.5.1 com MySQL e ambiente Linux que nos atende bem desde maio/2017.
Como temos os dados no sistema de BI, definimos que quando viermos a mudar de versão não faremos a migração do banco de dados, apenas vamos adaptar as views usadas para copiar para o BI.

luizboeri

Vera Boa tarde, pode deria me ajudar com algum docuemento de como fez para utilizar o banco em um BI?

loliveira456

Boa tarde. Alguém fez o script de migração ou poderia dar um exemplo da estrutura dele?

apessanha

Também estou com a mesma necessidade de migração. Não encontrei nada pronto ainda para migrar o banco do SGA, mas vi que existem ferramentas que possibilitam fazer esta ação, como usar Python com Pandas e SqlAlchemy, criando um script poderoso que consegue migrar e fazer transformação de grandes massas de dados, acredito que seja uma direção para fazer uma implementação. Também pensei em rodar uns comandos de drop, update e create numa cópia do banco antigo de forma que ele possa ser atualizado para o formato do schema do novo banco.
Outra abordagem que acredito ser possível, se a massa de dados não for muito grande, seria exportar para csv o db antigo, fazer alterações no arquivo de modo a permitir sua importação no db novo.

Próxima página »