Open David-Guillot opened 1 year ago
Merging #37 (de27e73) into master (fe1a773) will decrease coverage by
1.40%
. The diff coverage is95.94%
.
:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@ Coverage Diff @@
## master #37 +/- ##
==========================================
- Coverage 95.65% 94.26% -1.40%
==========================================
Files 12 12
Lines 576 628 +52
Branches 80 92 +12
==========================================
+ Hits 551 592 +41
- Misses 21 30 +9
- Partials 4 6 +2
Impacted Files | Coverage Δ | |
---|---|---|
django_opensearch_dsl/documents.py | 96.52% <93.75%> (-1.54%) |
:arrow_down: |
...o_opensearch_dsl/management/commands/opensearch.py | 94.02% <100.00%> (-5.98%) |
:arrow_down: |
django_opensearch_dsl/management/enums.py | 100.00% <100.00%> (ø) |
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.
@qcoumes did you have some time to think about this?
Sorry, had a lot of work last month, I'll look at this tomorrow
this feature will not be released immediately if you're OK with it.
Of course I'm okay with this, we're already relying on our fork's branch to benefit from this feature, we can continue doing so for a couple of months.
Fixes #2
Hi @qcoumes ,
This PR supersedes #23 in my attempts to implement #2 . This is a very different approach, based on the
Document
class much more than onIndex
class:Document
subclass to have multiple indices, by leveraging the ability ofopensearch_dsl
Document
class to do soindex rebuild
was removed because it was not making any sense anymore, anddocument migrate
has been added, but it doesn't do anything more than switching an alias (you need to callindex create
thendocument index
to actually put documents into your new index)index create
is working, as well asdocument migrate
, which delete the concrete index if it existsI'll let you judge if this architecture fits your vision of this lib. If it doesn't, I'll stop trying to implement #2 because it's been a lot of energy on my end, and if it needs another rewrite I'll just find a way to integrate this solution somewhere in our codebase, as an extension of this lib.