Server-tools: [RFC] base_elasticsearch

Привет @lasley в Akretion, мы, наверное, начали то, что вам нужно:
https://github.com/akretion/connector-nosql
также см. ветку solr https://github.com/akretion/connector-nosql/tree/9.0-solr
cc @sebastienbeau
пожалуйста, давайте поработаем над этим вместе. У нас уже есть большой опыт интеграции Odoo с хранилищами данных Solr и Algolia NoSQL.

Хорошо , спасибо

К сожалению, одним из требований моего проекта является то, что он должен быть LGPL - я должен был упомянуть об этом в моем RFC задним числом (отредактированный, чтобы включить его). Требование LGPL исключает использование connector , а также исключает включение этой логики в base_external_dbsource . Это требование связано с тем, что я планирую использовать этот модуль как часть моей основной инфраструктуры биллинга SaaS.

Я вижу здесь много логики экспорта, но ничего для чтения данных. Прав ли я в этой оценке?

Как вам удалось избежать необходимости хранить данные в Odoo?

@lasley Я автор логики в base_external_dbsource . Я просмотрел историю, и единственным другим оригинальным вкладом было добавление соединений Firebird DB. Если это важно, мы могли бы рассмотреть вопрос о перелицензировании этого модуля на LGPL.
Фактически, поскольку это всего лишь технические инструменты, я не вижу проблемы в том, чтобы репозиторий серверных инструментов был настолько большим, насколько это возможно, LGPL.

@dreispt - Я хотел бы добавить логику в существующий модуль, если вы хорошо разбираетесь в релицензии. Я собираюсь использовать эту базу для приема метрик и последующего выставления счетов за мои предложения SaaS, поэтому недопущение проникновения AGPL в нее является абсолютным препятствием.

Вначале все, что нам нужно, - это простое эластичное соединение, поэтому base_external_dbsource подходит. Я бы также, вероятно, немного реорганизовал его, чтобы избавиться от цепочек if внутри conn_open и execute которые будут экспоненциально увеличиваться по мере добавления новых источников.

NoSQL немного отличается с точки зрения запросов, но я все еще могу вписаться в интерфейс execute с небольшой творческой адаптацией.

@lasley ОК. Чтобы уважать все другие вклады, такие как перенос с версий, я открою проблему, чтобы предложить и обсудить изменение лицензии.
И мы должны сделать модуль «подключаемым», где поддержка дополнительных баз данных, таких как Firebird, может быть подключена дополнительным модулем.

Спасибо @dreispt - очень признателен!

По поводу pluggable - Что вы имели в виду? Мой запланированный рефакторинг на самом деле состоял только в том, чтобы разорвать две гигантские цепочки if, но я открыт для других улучшений, пока они находятся на моей платформе для разработчиков.

@lasley Я имею в виду облегчение расширения с помощью другого модуля. Дополнительная поддержка db может быть добавлена ​​дополнительным модулем расширения.

@dreispt Ах, да, попался. Определенно!

Есть ли у меня мысли о выделении всех независимых источников баз данных в их собственные модули? Я чувствую, что эта попытка / за исключением того, что вверху немного громоздка, вы согласны? Это текущее решение , но я думаю, что его еще можно улучшить.

Это то, чего мы должны ждать до v11 из-за стабильной версии? Или допустимо выпуск вместе с заменяющим модулем (модулями)?

Я также думаю, что, может быть, было бы неплохо добавить базовый интерфейс типа CRUD, чтобы, возможно, мы могли подумать об уходе от прямого SQL.

IMO было бы чище, если бы модуль расширения просто думал: наследовать модель base.external.dbsource для изменения функций и моделей.

Разумно извлечь поставщиков db для 10.0, поскольку это свежая версия, но, вероятно, это будет нецелесообразно для 9.0 - и обновление нарушит существующие установки.

10.0 уже выпущена и выглядит как миграция 1: 1. Я думаю, нам придется подождать до 11, чтобы придерживаться политики стабильного выпуска, верно?

Собственно говоря, да.
Это означает, что мы не должны удалять функции из текущего модуля.

Что, если бы мы сделали автоматическую установку новых модулей в более ранние версии? Разрешил бы изоляцию, пока я здесь, с легким выключением на потом.

Внешний интерфейс API будет таким же, поэтому я не думаю, что мы вызовем какие-либо проблемы?

@lasley Да, это хорошая идея.

Всем привет,

@lasley Может быть, вы захотите посмотреть https://github.com/camptocamp/odoo-elasticsearch-kibana

С уважением,

Joël

Следуя тому, что @jgrandguillaume показывает выше, мы просто обсуждаем с ним, что было бы здорово иметь такой инструмент, как https://github.com/OCA/reporting-engine/tree/8.0/bi_view_editor, для определения модели отчетности. в Odoo, а затем чтобы иметь возможность экспортировать данные для этой модели в ElasticSearch, чтобы их можно было объединить с другими источниками данных, а затем составить отчет по ним с помощью Kibana.

Я не совсем уверен, что @lasley придерживается этого подхода в этом RFC? ¿?

Интересно по обоим пунктам, спасибо @jgrandguillaume и @jbeficent.

bi_view_editor что @jbeficent связал обновленную форму sql_view которая связана как зависимость модуля для odoo-elasticsearch-kibana ?

У меня есть своего рода многоцелевое намерение с этим RFC. Основная цель - вывести статистику из Odoo, аналогично тому, как это делается в обеих связанных библиотеках.

Чуть позже мне нужно будет изменить некоторые пути данных. Kibana - отличный визуализатор для меня, но мне нужно будет создать некоторые информационные панели в Odoo для прямой отчетности через клиентские информационные панели.

@lasley См. bi_view_editor здесь: https://github.com/OCA/reporting-engine/tree/8.0/bi_view_editor. В настоящее время это не зависимость для odoo-elasticsearch-kibana . Это инструмент, который позволяет обычному пользователю разрабатывать модели Odoo для целей отчетности. Подобно выполнению sql_view, но сила в руках пользователя.

Мы также хотим вывести статистику из Odoo, и цель будет заключаться в том, чтобы у пользователя была возможность определять, какую статистику он хотел бы экспортировать из Odoo.

Обратный путь тоже был бы отличным.

@jbeficent - Это действительно круто. Создать что-то подобное для NoSQL, вероятно, будет намного проще из-за отсутствия взаимосвязей.

Мне, вероятно, нужно добавить некоторые методы для индексов в мой # 645, чтобы поддерживать что-то вроде этого, что потребует концепции анализа индексов, которую я не разрабатывал.

Пинг всем, кто интересуется - я помещаю предварительный дизайн данных в https://github.com/OCA/server-tools/pull/660#issuecomment -273583948, если кто-то хочет взглянуть. Здесь по-прежнему не будет фреймворка представления, но я думаю, что, возможно, мы на правильном пути.