Concept behind this fork
barseghyanartur opened this issue · 2 comments
At first sight, this seems like a copy of the upstream, which dependencies changed from Elasticsearch to OpenSearch. After some investigation, I discovered that it's actually not fully compatible with django-elasticsearch-dsl
functionality. The registry
module is either re-written or cleaned-up. Some of the functionality of the original package isn't available. I'm wondering, what's the idea behind this? What are the driving factors that require the change(s)? Why not just keep it in sync with upstream? I'm not trying to criticize. Only trying to understand whether this can be useful for me or not.
This is indeed a fork of django-elasticsearch-dsl
, the differences are mostly due to:
-
Some differences between OpenSearch and Elasticsearch.
Even thought they're mostly compatible since the fork of OpenSearch is still recent, these differences will only increase over time.
-
A lack of time.
I sadly don't have much time to allocate to this project, I chose to ensure the functionalities I needed were tested and working fine.
I guess you're asking this because you want to implement something akin to django-elasticsearch-dsl-drf
for OpenSearch. django-elasticsearch-dsl
is still in pre-release (0.3.0
at this time), and it can be a milestone for a 1.0.0
release to make it more compatible with your codebase.
Yes. Exactly. I have achieved that on the side of Elasticsearch and Elasticsearch DSL, but the Django integration part (which is in my eyes quite trivial) causes issues. Thanks for answering! Now I know what to do.