[okfn-br] Dúvidas com BD; Cuidando + Gastos Abertos; Servidor OK-Br
Luiz Armesto
luiz.armesto em gmail.com
Terça Julho 7 12:44:10 UTC 2015
A minha proposta é que discussão de questões técnicas sejam feitas na lista
gastosabertos [1].
Os issues do Github ficam para descrição de tarefas. Sempre que alguém for
realizar qualquer tarefa, deve ter um ticket aberto, com a descrição do que
será feito e assinado para aquela pessoa. Seja uma tarefa de
desenvolvimento, de administração de servidor, de pesquisa por soluções
técnicas... Assim evitamos trabalho duplicado e sabemos o que cada um está
fazendo. (vou abrir uma outra thread na lista do gastosabertos para
conversarmos sobre como nos organizarmos, esperem para responder esse ponto
nela)
Sobre a migração do cuidando para o gastosabertos, uma semana é suficiente
mesmo? Na minha opinião não basta passar a salvar os dados que eram salvos
na base de dados do cuidando em mongodb na base de dados do gastosabertos.
Tem que fazer realmente a utilização das funcionalidades de indexação
espacial do postgis, visto que atualmente os valores de longitude e
latitude do cuidando são salvos como simples colunas float. Os dados de
geolocalização não devem ser contaminados com códigos de erro, então nada
de "404" para representar valores que não foi possível fazer o geocoding. O
formato intermediário para os valores de geolocalização deve seguir um
padrão, de preferencia geojson que é suportado tanto pelo postgis quanto
pelo leaflet.
[1] https://lists.okfn.org/mailman/listinfo/gastosabertos
2015-07-07 8:03 GMT-03:00 Andres MRM <andres em inventati.org>:
>
> Bom dia Peter,
>
> Eu tinha dito uma semana para a migração de todos os dados. Por enquanto
> migrei só a receita e os contratos (que eram os que estavam em MySQL e nem
> estavam na conta inicial, já que eu achava que eles estavam em Postgres).
> Nesse momento estou cuidando da migração da execução. Mas aquele prazo de
> uma
> semana (depois eu percebi que não fui bem claro) era pensando não só nessa
> migração inicial (que deve levar menos tempo), mas também o custo a mais de
> desenvolvimento quando realmente for usar o PostGIS, ou precisar adicionar
> novas funcionalidades que PythoEve+MongoDB já davam "de graça".
>
> Sobre a doc, realmente precisamos definir melhor isso... Vamos tentar
> pensar:
> O que documentar e onde?
>
> - Mais especificamente sobre os dados que usamos (que eu até fui meio
> chatinho
> com você quanto a isso), a documentação está centralizada aqui:
> https://pt.wikiversity.org/wiki/Gastos_Abertos/Prot%C3%B3tipo
> - Doc da API. Por enquanto está na wiki GitHub do GA, mas em algum momento
> ela
> será gerada automaticamente em outro lugar.
> - Doc de instalação. Estou tentando registrar os passos necessários para
> instalar o projeto, mas isso ainda não está consolidado. Ficaria no
> repositório.
> - Documento sobre como contribuir, na linha do que o Raniere propôs. Esse
> precisamos pensar melhor como fazer... Ficaria no repositório também? É
> só
> para quem programa? E quem não programa e quer contribuir?
> - Descrição sobre o projeto. Eu consigo pensar em uma parte mais técnica e
> outra mais geral. No Cuidando estou deixando na Wiki do GitLab/GitHub.
> Mas
> seria bom pensar qual o mínimo de coisas que ela tem que ter.
>
> - O que mais precisaria ser documentado/consolidado?
>
>
> Depois a parte de comunicação... Estou enviando os e-mails todos para
> GA+OK-Br porque foi isso que entendi que era para fazer. E de certa forma
> acho
> bacana porque vira e mexe aparece alguma pessoa nova comentando. Mas se
> acharem que é muito SPAM, por mim podemos mudar.
>
>
> Abs!
>
>
>
> Quoting Peter Krauss (2015-07-07 07:31:37)
> > Bom dia Andres,
> >
> > A estimativa era (até onde lembro pois não consta em ata ou trello) de
> que o
> > processo de migração para PostgreSQL v9.3+
> > tomasse no máximo uma semana de trabalho...
> > Pelo que estou vendo, tomou só um dia (!) e, a menos de testes e
> feedbacks da
> > equipe, está feito...
> > Parabéns!
> >
> > - - - -
> > Nota geral (Bom dia a todos do Gastos+Cuidando!),
> > sobre "probleminhas técnicos presentes e futuros": onde é melhor
> discuti-los?
> >
> > Pelo que entendi isso tudo agora é responsabilidade do Gastos Abertos
> (nada de
> > dados cadastrais no Cuidando), então temos:
> > * Lista geral da OKBr (aqui okfn-br em lists.okfn.org)
> > * Lista do Gastos (gastosabertos em lists.okfn.org)
> > * github.com/okfn-brasil/gastos_?? (/issue ou /wiki?)
> > * Wiki geral do Gastos
> > * (...difícil decidir onde...)
> >
> > Onde a equipe Gastos julga que é melhor fazer a discussão "altamente
> técnica"
> > da coisa?
> > Não teria como "criar regra" para evitar de poluir canal inadequado, e de
> > ninguém mais ficar perdido?
> >
> > - - - -
> > PS1: o Cuidando2 tem como foco os dados geocodificados, mas se a
> geocodificação
> > é também responsabilidade do Gastos, então o Cuidando2 nem precisa cuidar
> > disso.... Ainda assim, existem demandas comuns sob responsabilidade do
> > Cuidando2, a arquitetura de web-services e protocolo de autenticação
> estavam
> > sendo discutidos na equipe do Cuidando2...
> >
> > PS2: a deliberações da "cúpula do Gastos+Cuidando" deveriam ser
> registradas em
> > ATA (no link é um rascunho aguardando revisão dos participantes da
> reunião).
> > ...Estou imaginando/supondo da reunião, que as especificações
> funcionais e
> > requisitos do "escopo arquitetura" seriam responsabilidade do Cuidando2.
> >
> >
> >
> > Em 6 de julho de 2015 19:45, Andres MRM <andres em inventati.org> escreveu:
> >
> >
> > Migrei os dados atuais do GA para o Postgres. Aparentemente está
> > funcionando:
> > http://gastosabertos.org/receitas
> > http://demo.gastosabertos.org/contratos
> > (Havia um probleminha de ints que passaram a ser floats e apareceram
> assim
> > na interface. Arrumei, mas pode ter outras falhas que não vi.)
> > Vamos se assim para o erro aleatório que estava dando também...
> >
> > Luiz e Edgar, importei os contratos usando o "import_contrato.py". O
> > "import_contrato_urls.py" não consegui fazer funcionar, não sei se
> era para
> > usá-lo também, mas pelo que vi o site está normal.
> > Mudei a pasta da instância para a home. Espero que assim não dê
> problema
> > caso
> > a máquina seja reiniciada...
> >
> >
> > Quoting Peter Krauss (2015-07-06 13:00:04)
> > > A minha proposta é a mesma de antes (falta definirmos Wiki's links
> > perdidos), e
> > > me parece compatível com o seu levantamento:
> > >
> > > * sem pensar: <ID, JSON> ou <ID, TEXT[]> ou seja, "FLEX";
> > >
> > > * pensando (planejando o conjunto completo de dados, se surgirem
> demandas
> > joins
> > > e indexações): <ID, chave1, chave2, restoFLEX>
> > >
> > > O segundo parece mais chatinho, mas tem como automatizar no
> PostgreSQL.
> > >
> > >
> > >
> > >
> > > Em 6 de julho de 2015 11:46, Andres MRM <andres em inventati.org>
> escreveu:
> > >
> > >
> > > Dei um "apt-get -f install" que aparentemente arrumou as
> dependências
> > do
> > > MariaDB.
> > >
> > > Consegui então instalar o Postgres 9.4 seguindo isso aqui:
> > > http://www.postgresql.org/download/linux/ubuntu/
> > > Vou ver agora se migro os dados do GA para ele e começo a
> colocar os
> > novos
> > > dados de execução nele também.
> > >
> > > Sobre esses últimos conversei no canal do IRC do SQLAlchemy
> sobre a
> > questão
> > > e
> > > me recomendaram ou usar uma coluna no BD para cada coluna da
> planilha
> > > (mesmo
> > > que várias delas vazias para alguns anos) ou usar o tipo JSON.
> Ainda
> > não
> > > sei,
> > > mas acho que vou pelo JSON...
> > >
> > >
> > > Quoting Peter Krauss (2015-07-03 13:10:33)
> > > >
> > > >
> > > > Em 3 de julho de 2015 12:33, Andres MRM <
> andres em inventati.org>
> > escreveu:
> > > >
> > > >
> > > > Quoting Peter Krauss (2015-07-03 11:57:28)
> > > > > O primeiro para o coletivo aqui poder ajudar é
> documentar:
> > se
> > > precisar
> > > > ajudo,
> > > > > sugiro na
> > > > > https://github.com/okfn-brasil/cuidando2/wiki
> > > > > é fundamental saber o perfil dessas tabelas (cabeçalho
> de
> > colunas
> > > basta),
> > > > e ter
> > > > > uma legenda no que for relevante.
> > > > Basicamente são Integers e Strings. Mas tem datas
> também, menos
> > > relevantes.
> > > >
> > > > > Em seguida entender o que seria "chave primária"
> (candidatos)
> > de
> > > cada
> > > > uma, para
> > > > > avaliarmos se ao menos isso foi preservado ao longo
> dos anos.
> > > > As colunas basicamente são códigos (int) e a descrição
> de cada
> > código
> > > > (str).
> > > > Aparentemente todos esses códigos são necessários para
> > construir uma
> > > chave
> > > > primária. Um jeito seria construir uma str que é a
> somatória de
> > todos
> > > esses
> > > > ints e colocar em uma nova coluna:
> > > >
> > > > 2015.23.49.8787.73898798
> > > >
> > > > Mas, como disse antes, o número de códigos varia ao
> longo dos
> > anos,
> > > então
> > > > algumas chaves seriam compostas por mais ou menos ints.
> > > >
> > > >
> > > > Se tá difícil documentar na Wiki, pode ser um simples Excel
> > (GoogleDocs)
> > > > mostrando exemplo dos cabeçalhos (não interessa tanto o tipo
> do
> > valor mas
> > > ter
> > > > uma ideia da semântica para consolidar as chaves-candidatas
> ... Eu
> > > costumo
> > > > documentar com uma linha de cabeçalho e uma linha de
> exemplo, ou
> > seja,
> > > duas
> > > > linhas a cada tipo de tabela).
> > > >
> > > >
> > > >
> > > >
> > > > > PostgreSQL v9.3: por favor não perca tempo com versões
> > anteriores,
> > > pois
> > > > sei que
> > > > > todos curtem JSON (!) na OKBr.
> > > >
> > > > Esse é outro problema, a versão que há para instalar no
> > servidor é o
> > > 9.1.
> > > > Teria que puxar um mais recente dos outros repositórios
> e rezar
> > para
> > > não
> > > > quebrar outro pacote...
> > > >
> > > > > Se deixar as colunas "de chave" SQL-normais, e as
> demais
> > colunas
> > > > codificadas
> > > > > num campo só com JSON, terá tudo de bom que já tinha no
> > Mongo.
> > > > > ... e antes de bater o martelo num tabelão universal,
> > > >
> > > > Teria que ver qual o suporte do SQLAlchemy para JSON no
> > Postgres.
> > > Porque se
> > > > não for para usar SQLAlchemy teria que reescrever a API
> atual
> > do GA
> > > também.
> > > > E se fosse para ir por ai, me parece mais razoável
> migrar tudo
> > para o
> > > > MongoDB
> > > > e pronto...
> > > >
> > > >
> > > > SQLAlchemy (ou o framework-SQL que for) não vai diferenciar
> tabela
> > bruta
> > > de
> > > > VIEW-SQL,
> > > > a modelagem de dados inclui conceber as VIEWs.
> > > >
> > > >
> > > >
> > > >
> > > > E outra coisa, deixando uma parte em JSON dá para cruzar
> os
> > dados
> > > depois
> > > > com
> > > > as outras tabelas (ex: receita) "de boa"? Será que não
> vai dar
> > tanto
> > > > trabalho
> > > > quanto interfacear com o Mongo via FDW?
> > > >
> > > > > - Além disso, pelo que consegui entender no
> servidor, os
> > dados
> > > atuais
> > > > de
> > > > > receita e contratos não estão em um Postgres,
> mas sim
> > num
> > > MariaDB.
> > > > Logo
> > > > > teríamos que migrá-los também para um
> Postgres... A não
> > ser
> > > que
> > > > alguém ai
> > > > > defenda deixar tudo no MariaDB. Não sei como é o
> NoSQL/
> > GIS
> > > dele...
> > > > >
> > > > > Essa parte é tranquila, posso ajudar.
> > > >
> > > > Em teoria o SQLAlchemy cuidaria disso sozinho. Seria só
> mudar o
> > link
> > > para o
> > > > BD
> > > > nele e reimportar os dados. Mas nunca se sabe o que pode
> > acontecer...
> > > >
> > > >
> > > > Mais uma vez, vamos documentar: outra coisa simples de
> colocar na
> > Wiki é
> > > uma
> > > > descrição sucinta do atual modelo de dados, para conferir o
> grau de
> > > impacto (se
> > > > zero ou mais) das mudanças propostas.
> > > >
> > > >
> > > >
> > > > > Infra da OKBr: é um problema sério que nasce com os
> problemas
> > de
> > > > governança.
> > > > > Na minha opinião deveria haver uma infra mínima
> unificada,
> > decente
> > > e para
> > > > todos
> > > > > os projetos.
> > > >
> > > > Bom, esse servidor É uma infra mínima unificada, e esse
> é o
> > problema:
> > > puxa
> > > > de
> > > > um lado, quebra do outro... Isso quando não quebra sem
> nem
> > ninguém
> > > entender
> > > > o
> > > > que foi.
> > > >
> > > >
> > > > Servidores com bom suporte a PostreSQL custam nos EUA o
> máximo
> > US$10/mês
> > > (!!)
> > > > (para esse volume de dados e freq. de acesso que temos)
> > > > é um absurdo a OKBr não ser capaz de oferecer isso para os
> > projetos..
> > > Mais
> > > > absurdo ainda um projeto de ~R$500k
> > > > não poder oferecer isso ao desenvolvedor.
> > > > ... Como eu coloquei antes, é uma questão de governança-OKBr
> (todos
> > os
> > > > projetos)...
> > > > Eu sugiro uma reunião técnico-deliberativa (deliberativa!)
> sobre o
> > > assunto...
> > > > :-)
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > okfn-br mailing list
> > > > okfn-br em lists.okfn.org
> > > > https://lists.okfn.org/mailman/listinfo/okfn-br
> > > > Unsubscribe:
> https://lists.okfn.org/mailman/options/okfn-br
> > > >
> > > >
> > > _______________________________________________
> > > okfn-br mailing list
> > > okfn-br em lists.okfn.org
> > > https://lists.okfn.org/mailman/listinfo/okfn-br
> > > Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br
> > >
> > >
> > _______________________________________________
> > okfn-br mailing list
> > okfn-br em lists.okfn.org
> > https://lists.okfn.org/mailman/listinfo/okfn-br
> > Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br
> >
> >
> _______________________________________________
> okfn-br mailing list
> okfn-br em lists.okfn.org
> https://lists.okfn.org/mailman/listinfo/okfn-br
> Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br
>
--
Luiz Armesto
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.okfn.org/pipermail/okfn-br/attachments/20150707/dcf9b92a/attachment-0005.html>
Mais detalhes sobre a lista de discussão okfn-br