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 <[email protected]> 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 > [email protected] > https://lists.okfn.org/mailman/listinfo/okfn-br > Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br > > _______________________________________________ okfn-br mailing list [email protected] https://lists.okfn.org/mailman/listinfo/okfn-br Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br
