valantic / pimcore-elastica-bridge Goto Github PK

By @danrot

Sometimes the wrong index is used, e.g. something like course_23042023 instead of course--green or course--blue. Seems like the only check is if the index starts with the given string.

à la Elasticsearch Head

• size
• # docs
• alias (for green/blue)

requested by @pryserv

Instead of --no-delete, use --delete etc.

suggested by @pryserv

Especially in the context for Pimcore Enterprise setups, the default should be more sensible.

E.g. \Valantic\ElasticaBridgeBundle\Index\AbstractIndex::getDocumentFromElement, \Valantic\ElasticaBridgeBundle\Index\AbstractIndex::searchForElements, and \Valantic\ElasticaBridgeBundle\Index\AbstractIndex::documentResultToElements as they encourage loading data from Elasticsearch and Pimcore which is often inefficient.

The Service should also be aware of possible locks so a soon to be bad index won't be updated. This way we could implement a messenger queue which waits with the update until the lock is available.

IMO The index should not be updated if pimcore autosaves a concrete or a new version is saved. WDYT?

e.g. replace event listener (sync) with messages (async)

The trait is rarely if ever overridden and virtually always used in the same class.

The stats (e.g. doc count) use values from the all section rather than primaries which results in e.g. double-counting the documents.

E.g. to index all documents or assets.

When running :status, the list of non-bundle indices is not sorted in any meaningful way. Since this command is primarily meant to be human-readable, alphabetical sort is probably the best way to go.

By @danrot

Currently this is done in the RefreshCommand, where an event listener is called manually with a manually created event. IMO it should be easier to execute that, especially in the context of the application. I have something like $index->refresh($element) in mind.

Currently, a Pimcore autosave triggers an element refresh. This can be seen as both a bug and a feature. Solutions:

1. Introduce a Symfony Config option for assets / data objects / documents to disable that feature (default is enable for BC reasons)
2. Offer tagged interfaces with a supports strategy to provide custom logic

For simplicity reasons, option 1 will be implemented. If advanced logic is needed, a project can define a listener with a higher priority than what's defined in \Valantic\ElasticaBridgeBundle\EventListener\Pimcore\ChangeListener::getSubscribedEvents and call \Valantic\ElasticaBridgeBundle\EventListener\Pimcore\ChangeListener::disableListener.

Assets are yet to be used in an index, nothing should prevent it from working though.

A failed index should not activate blue/green switch

Use rector

By @danrot

I think it would be better to have just one DocumentInterface. It would make this bundle easier to understand and maintain. It would still be easily possible to have an abstract class just to extract the parts that might be reused among multiple indices, if the developer wishes to do that.

The trait is incredibly useful yet lacks clear documentation and the code isn't easy to parse either.

Follow up to #61

E.g. \Valantic\ElasticaBridgeBundle\DocumentType\DocumentInterface::TYPES

Meta fields e.g. __subType (https://github.com/valantic/pimcore-elastica-bridge/blob/main/src/Document/DocumentInterface.php#L19-L30) aren't mapped as keyword attributes in ‎IndexInterface::getMapping by default even though this would provide a sane default.