Server-tools: [RFC] base_elasticsearch

Olá @lasley da Akretion, provavelmente começamos o que você precisa:
https://github.com/akretion/connector-nosql
veja também o branch solr https://github.com/akretion/connector-nosql/tree/9.0-solr
cc @sebastienbeau
por favor, vamos trabalhar nisso juntos. Já temos uma grande experiência com a integração do Odoo com os armazenamentos de dados Solr e Algolia NoSQL.

Legal, obrigado @rvalyi - parece mesmo que você começou o que eu precisava.

Infelizmente, um dos requisitos do meu projeto é que ele deve ser LGPL - eu deveria ter mencionado isso em meu RFC em retrospectiva (editado para incluí-lo). O requisito LGPL exclui o uso de connector e também exclui a inclusão dessa lógica em base_external_dbsource . Esse requisito se deve ao uso planejado deste módulo como parte da minha infraestrutura de faturamento SaaS principal.

Vejo muita lógica de exportação aqui, mas nada para ler os dados. Estou correto nessa avaliação?

Como você contornou a necessidade de armazenar dados no Odoo?

@lasley sou o autor da lógica de base_external_dbsource . Eu olhei para o histórico e a única outra contribuição original é adicionar as conexões do Firebird DB. Se for importante, podemos considerar relicenciar esse módulo para LGPL.
Na verdade, como são apenas ferramentas técnicas, não vejo problema em que o repositório de ferramentas de servidor seja o mais LGPL possível.

@dreispt - Eu adoraria adicionar a lógica ao módulo existente se você for bom com o relicenciamento. Vou usar essa base para ingestão de métricas e faturamento subsequente de minhas ofertas de SaaS, portanto, não permitir que o AGPL penetre nisso é um bloqueador absoluto.

No início, uma simples conexão elástica é tudo de que precisamos também, então base_external_dbsource se encaixa. Eu provavelmente também o refatoraria um pouco para me livrar das cadeias if dentro de conn_open e execute que se tornarão exponencialmente maiores à medida que mais fontes começarem a ser adicionadas.

NoSQL é um pouco diferente em termos de consulta, mas ainda posso me encaixar na interface execute com um pouco de adaptação criativa.

@lasley OK. Para respeitar todas as outras contribuições, como a transferência de versões, abrirei um problema para propor e discutir a alteração da licença.
E devemos tornar o módulo "plugável", onde o suporte a bancos de dados adicionais, como o Firebird, pode ser plugado por um módulo adicional.

Obrigado @dreispt - muito apreciado!

Sobre pluggable - O que você tem em mente? Minha refatoração planejada foi realmente apenas para quebrar as duas cadeias gigantes de if, mas estou aberto a outras melhorias enquanto estiver na minha placa de desenvolvimento.

@lasley, quero dizer tornar mais fácil ser extensível por outro módulo. Suporte de banco de dados adicional pode ser adicionado por um módulo de extensão adicional.

@dreispt Ahhh sim

Alguma idéia de como retirar todas as fontes de banco de dados independentes em seus próprios módulos? Acho que essa coisa de tentar / exceto no topo é um pouco difícil de manejar, você concorda? Esta é a solução atual , mas acho que ainda pode ser melhorada.

Isso é algo que temos que esperar para a v11 devido ao lançamento estável? Ou a liberação junto com um (s) módulo (s) de substituição é aceitável?

Eu também acho que talvez seja bom adicionar uma interface do tipo CRUD básico para que possamos pensar em deixar de usar o SQL direto.

IMO, seria mais limpo para o módulo de extensão apenas fazer o pensamento usual: herdar o modelo base.external.dbsource para modificar recursos e modelos.

É razoável extrair os provedores de banco de dados para 10.0, já que é uma versão nova, mas provavelmente não será razoável para 9.0 - e a atualização interromperia as instalações existentes.

10.0 já foi lançado e parece ser uma migração 1: 1. Acho que teríamos que esperar até 11 para aderir à política de versão estável, certo?

Estritamente falando, sim.
Isso significa que não devemos remover recursos do módulo atual.

E se fizéssemos a instalação automática dos novos módulos nas versões anteriores? Permitiria o isolamento enquanto estou aqui, com um interruptor fácil de desligar para mais tarde.

A API externa será a mesma, então não acho que causaríamos problemas.

@lasley Sim, é uma boa ideia.

Olá,

@lasley Pode ser que você queira dar uma olhada em https://github.com/camptocamp/odoo-elasticsearch-kibana

Cumprimentos,

Joël

Seguindo com o que @jgrandguillaume mostra acima, nós apenas discutimos com ele que o que seria ótimo seria ter uma ferramenta como https://github.com/OCA/reporting-engine/tree/8.0/bi_view_editor para definir o modelo de relatório no Odoo e, em seguida, ser capaz de exportar os dados para este modelo no ElasticSearch, de modo que possa ser combinado com outras fontes de dados e, em seguida, gerar relatórios sobre ele usando Kibana.

Agora, eu não tenho certeza se essa é a abordagem que @lasley está seguindo neste RFC? ¿?

Interessante em ambos os aspectos, obrigado @jgrandguillaume & @jbeficent.

É bi_view_editor que @jbeficent vinculou a forma atualizada do sql_view que está vinculado como uma dependência de módulo para odoo-elasticsearch-kibana ?

Tenho uma espécie de intenção polivalente com este RFC. A intenção principal é empurrar as estatísticas para fora do Odoo, semelhante ao que está sendo feito em ambas as bibliotecas vinculadas.

Um pouco mais adiante, vou precisar reverter alguns dos caminhos de dados. Kibana é um ótimo visualizador para mim, mas vou precisar construir alguns dos painéis no Odoo para relatórios diretos por meio dos painéis do cliente.

@lasley Veja bi_view_editor aqui: https://github.com/OCA/reporting-engine/tree/8.0/bi_view_editor. Atualmente não é uma dependência de odoo-elasticsearch-kibana . É uma ferramenta que permite a um usuário normal projetar modelos Odoo para fins de relatório. Semelhante a fazer um sql_view, mas o poder está nas mãos do usuário.

Também queremos enviar estatísticas para fora do Odoo, e o objetivo é que o usuário tenha a capacidade de projetar quais estatísticas gostaria de exportar do Odoo.

O caminho inverso também seria ótimo.

@jbeficent - Bem, isso é muito legal, de fato. Criar algo assim para NoSQL provavelmente seria muito mais fácil devido à falta de relações.

Provavelmente, preciso adicionar alguns métodos para índices em meu # 645 para dar suporte a algo como isso, que precisaria de um conceito de análise de índice que eu não desenvolvi.

Faça ping para qualquer pessoa interessada - coloquei um design de dados preliminar em https://github.com/OCA/server-tools/pull/660#issuecomment -273583948 se alguém quiser dar uma olhada. Ainda faltaria uma estrutura de visão, mas acho que talvez nos coloque no caminho certo.