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

Luiz Armesto luiz.armesto em gmail.com
Terça Julho 7 13:52:00 UTC 2015


O postgis tem as funções "ST_AsGeoJSON" que devolve um geojson e
"ST_GeomFromGeoJSON" que devolve um objeto de geometria do postgis a partir
de um geojson.

2015-07-07 10:29 GMT-03:00 Andres MRM <andres em inventati.org>:

>
> Falei uma semana pensando em trabalho extra por abandonar
> MongoDB+PythonEve.
> Há coisas que já precisariam ser feitas de qualquer jeito (como a
> padronização
> de todos os anos dos dados de execução, que fiz semana passada). Mas sim, é
> possível que o custo extra total por se adotar PostGIS no lugar de MongoDB
> seja maior que uma semana... Ou não. É difícil estimar...
>
> Não sabia que PostGIS também suporta GeoJSON, depois vejo se o GeoAlchemy
>> implementou isso.
>
>
> Quoting Luiz Armesto (2015-07-07 09:44:10)
> > 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
> _______________________________________________
> Gastosabertos mailing list
> Gastosabertos em lists.okfn.org
> https://lists.okfn.org/mailman/listinfo/gastosabertos
>



-- 
Luiz Armesto
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.okfn.org/pipermail/gastosabertos/attachments/20150707/ce22d562/attachment-0003.html>


Mais detalhes sobre a lista de discussão Gastosabertos