Server-tools: [RFC] base_elasticsearch

안녕하세요 @lasley at Akretion 우리는 아마도 당신이 필요로 하는 것을 시작했을 것입니다:
https://github.com/akretion/connector-nosql
solr 분기도 참조하십시오. https://github.com/akretion/connector-nosql/tree/9.0-solr
cc @sebastienbeau
이 작업을 함께 해주세요. 우리는 이미 Odoo를 Solr 및 Algolia NoSQL 데이터 저장소와 통합한 경험이 있습니다.

좋은, 감사합니다 @rvalyi - 정말로 당신이 내가 필요한 것을 시작한 것 같습니다.

불행히도 내 프로젝트의 요구 사항 중 하나는 LGPL이어야 한다는 것입니다. 나중에 RFC에서 언급했어야 했습니다(포함하도록 편집됨). LGPL 요구 사항은 connector 의 사용을 배제하고 이 논리를 base_external_dbsource 포함하는 것도 배제합니다. 이 요구 사항은 이 모듈을 핵심 SaaS 청구 인프라의 일부로 사용할 계획 때문입니다.

여기에서 많은 내보내기 논리를 볼 수 있지만 데이터를 읽기 위한 것은 없습니다. 그 평가에서 내가 옳습니까?

Odoo에 데이터를 저장해야 하는 필요성을 어떻게 우회했습니까?

@lasley 저는 base_external_dbsource 논리의 저자입니다. 나는 역사를 보았고 유일한 다른 독창적 인 기여는 Firebird DB 연결을 추가하는 것입니다. 중요하다면 해당 모듈을 LGPL로 재라이센스하는 것을 고려할 수 있습니다.
사실, 그것들은 단지 기술적인 도구이기 때문에, 나는 server-tools repo가 ​​가능한 한 많은 LGPL이 되는 문제를 보지 않을 것입니다.

@dreispt - 재라이센스에 능숙하다면 기존 모듈에 로직을 추가하고 싶습니다. 나는 이 기반을 메트릭 수집 및 내 SaaS 제품의 후속 청구에 사용할 것이므로 AGPL이 여기에 침투하는 것을 허용하지 않는 것은 절대적인 차단입니다.

처음에는 간단한 Elastic 연결만 있으면 충분하므로 base_external_dbsource 적합합니다. 또한 conn_open 및 execute 내부의 if 체인을 제거하기 위해 약간 리팩토링할 것입니다. 이 체인은 더 ​​많은 소스가 추가되기 시작하면 기하급수적으로 커질 것입니다.

NoSQL은 쿼리 측면에서 약간 다르지만 약간의 창의적인 적응으로 execute 인터페이스에 들어갈 수 있습니다.

@lasley 알았어. 버전에서 이식하는 것과 같은 다른 모든 기여를 존중하기 위해 문제를 열어 라이선스 변경을 제안하고 논의할 것입니다.
그리고 Firebird와 같은 추가 데이터베이스에 대한 지원을 추가 모듈로 연결할 수 있는 모듈을 "플러그 가능"하게 만들어야 합니다.

@dreispt 감사합니다. 감사합니다!

pluggable - 무엇을 염두에 두셨습니까? 내 계획된 리팩토링은 실제로 두 개의 거대한 if 사슬을 깨뜨리는 것이었지만 내 개발 판에 있는 동안 다른 개선 사항에 대해 열려 있습니다.

@lasley 다른 모듈로 쉽게 확장할 수 있도록 하는 것입니다. 추가 확장 모듈을 통해 추가 db 지원을 추가할 수 있습니다.

@dreispt 아

모든 독립 데이터베이스 소스를 자체 모듈로 제거할 생각이 있습니까? 상단에 있는 이 시도/제외 항목이 다소 다루기 힘든 것 같습니다. 동의하십니까? 이것은 현재 솔루션 이지만 여전히 개선될 수 있다고 생각합니다.

이것은 안정적인 릴리스 때문에 v11까지 기다려야 하는 것입니까? 아니면 교체 모듈과 함께 출시해도 됩니까?

또한 기본 CRUD 유형 인터페이스를 추가하여 직접 SQL에서 벗어나는 것을 생각할 수도 있다고 생각합니다.

IMO 확장 모듈이 일반적인 생각을 하는 것이 더 깨끗할 것입니다. base.external.dbsource 모델을 상속하여 기능과 모델을 수정합니다.

새로운 버전이기 때문에 10.0에 대한 db 공급자를 추출하는 것이 합리적이지만 9.0에는 합리적이지 않을 수 있으며 업데이트하면 기존 설치가 중단됩니다.

10.0은 이미 릴리스되었으며 1:1 마이그레이션으로 보입니다. 안정적인 출시 정책을 준수하려면 11시까지 기다려야 할 것 같은데요?

엄밀히 말하면 그렇습니다.
즉, 현재 모듈에서 기능을 제거해서는 안 됩니다.

새 모듈을 더 낮은 버전에서 자동 설치하도록 하면 어떻게 될까요? 내가 여기에 있는 동안 격리를 허용하고 나중에 사용할 수 있도록 스위치를 쉽게 끌 수 있습니다.

외부 대면 API는 동일하므로 문제가 발생하지 않을 것 같은데요?

@lasley 예, 좋은 생각입니다.

안녕하세요,

@lasley https://github.com/camptocamp/odoo-elasticsearch-kibana 를 보고 싶을 수도 있습니다.

문안 인사,

조엘

위에서 @jgrandguillaume이 보여준 것에 이어 보고 모델을 정의하기 위해 https://github.com/OCA/reporting-engine/tree/8.0/bi_view_editor 와 같은 도구가 있으면 좋을 것이라고 그와 논의했습니다. Odoo에서 이 모델의 데이터를 ElasticSearch로 내보내 다른 데이터 소스와 결합한 다음 Kibana를 사용하여 보고할 수 있습니다.

이제 @lasley 가 이 RFC에서

두 가지 면에서 모두 흥미롭습니다. @jgrandguillaume & @jbeficent에게 감사드립니다.

odoo-elasticsearch-kibana 대한 모듈 종속성으로 연결된 sql_view 의 업그레이드된 형태를 @jbeficent 가 연결한 bi_view_editor odoo-elasticsearch-kibana 입니까?

나는 이 RFC에 일종의 다목적 의도를 가지고 있습니다. 주요 목적은 연결된 두 라이브러리에서 수행되는 것과 유사하게 Odoo에서 통계를 내보내는 것입니다.

조금 더 내려가면 일부 데이터 경로를 반대로 해야 합니다. Kibana는 저에게 훌륭한 시각화 도구이지만 클라이언트 대시보드를 통한 직접 보고를 위해 Odoo에서 일부 대시보드를 구축해야 합니다.

@lasley 여기에서 https://github.com/OCA/reporting-engine/tree/8.0/bi_view_editor. 현재 odoo-elasticsearch-kibana 대한 종속성이 아닙니다. 일반 사용자가 보고 목적으로 Odoo 모델을 설계할 수 있는 도구입니다. sql_view를 수행하는 것과 유사하지만 권한은 사용자에게 있습니다.

우리는 또한 Odoo에서 통계를 내보내고자 하며 목표는 사용자가 Odoo에서 내보내고 싶은 통계를 디자인할 수 있는 기능을 갖는 것입니다.

역방향 경로도 좋습니다.

@jbeficent - 정말

내가 개발하지 않은 인덱스 분석 개념이 필요한 이와 같은 것을 지원하려면 인덱스에 대한 몇 가지 메서드를 #645에 추가해야 할 것입니다.

관심 있는 모든 사람에게 Ping - 보고 싶은 사람이 있으면 https://github.com/OCA/server-tools/pull/660#issuecomment -273583948에 예비 데이터 디자인을 넣었습니다. 이것은 여전히 ​​뷰 프레임워크가 부족하지만 올바른 방향으로 나아갈 수 있다고 생각합니다.