[okfn-br] Dúvidas com BD; Cuidando + Gastos Abertos; Servidor OK-Br

Terça Julho 7 10:31:37 UTC 2015

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_??
<https://github.com/okfn-brasil?utf8=%E2%9C%93&query=gastos_>   (/issue ou
/wiki?)
* Wiki geral do Gastos <https://pt.wikiversity.org/wiki/Gastos_Abertos>
* (...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*
<http://wiki.okfn.org/Open_Knowledge_Brasil/Reuni%C3%B5es/2015-07-01-interProjs>
(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
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.okfn.org/pipermail/okfn-br/attachments/20150707/1ad670ea/attachment-0005.html>