[POC] Implented working config with multiple indexes per document class

[toooni]

I've made a proof of concept for a solution where we can have multiple indexes for one document class again (#902). The config can look like this:

ongr_elasticsearch: indexes: package_de_chf: class: App\Document\Package alias: package_de_chf hosts: - '%env(ELASTICSEARCH_ENDPOINT)%' package_fr_chf: class: App\Document\Package alias: package_fr_chf hosts: - '%env(ELASTICSEARCH_ENDPOINT)%' App\Document\PackageIsochrone: hosts: - '%env(ELASTICSEARCH_ENDPOINT)%' 

If a class parameter is provided the indexes children keys can be a self defined string which will be used as the index service name (if package_de_chf is used, the service will be called ongr.es.index.package_de_chf).

I abused the IndexSettings class to create a temporary storage before creating the definition. I am not sure if this is a good solution or if we should just work with a separate class (only difference would be the propertyMetadata).

I've also removed the return values from the setters since those are not used anywhere.

This PR can probably be targeted to the 6.2 branch too.

[codecov-io]

Codecov Report

Merging #917 into 7.0 will increase coverage by 0.99%.
The diff coverage is 82.47%.

@@ Coverage Diff @@ ## 7.0 #917 +/- ## ============================================ + Coverage 83.16% 84.15% +0.99%  - Complexity 413 425 +12  ============================================ Files 39 39 Lines 1360 1395 +35 ============================================ + Hits 1131 1174 +43  + Misses 229 221 -8

Impacted Files	Coverage Δ	Complexity Δ
Mapping/IndexSettings.php	78.94% <64.28%> (+43.81%)	15 <8> (+2)	⬆️
DependencyInjection/Compiler/MappingPass.php	88.39% <85.54%> (-3.92%)	26 <7> (+10)
Mapping/DocumentParser.php	84.52% <0%> (-0.6%)	58% <0%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 428d21e...02be3d3. Read the comment docs.

[toooni]

@saimaz Can I have an opinion on the proposed changes? I am not even sure this goes far enough. I think the new approach by using the class name as service name is generally flawed and you should rethink this design decision.
Also having the services public doesn't seem to follow best practices. IMO there should still be something like a manager container. The container would contain the lazy index services and returns them by name without the need of a prefix.

[saimaz]

The current architecture does not support multiple indexes for the same document. I'm fully aware that the current approach is not seamless how OOP law directs.

The main idea was to simplify as much as possible to work with the document as the index. For me, personally, the current approach is very handy.

Having said that I'm very open for suggestions, PR's or anything else that might help.

[toooni]

Thank you for your response. Ok, with the approach I've implemented both will be possible. Can you review it? I'll create separate PR with my idea for the container approach later.
FYI: I've tested the proposed changes in this PR with our application @ weekend4two.com and had no issues (I've used both class names and manual names for the service names).

[saimaz]

Sure, I'l take a look

[toooni]

@saimaz Any idea when you will have a chance to look at this PR?

[toooni]

Hi @saimaz. I just wanted to ask again if there is a chance to have this PR reviewed? Or if you don't want to allow the same document used in multiple services?