PHPackages                             loyaltycorp/search - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [Search & Filtering](/categories/search)
4. /
5. loyaltycorp/search

Abandoned → [eonx-com/search](/?search=eonx-com%2Fsearch)Library[Search & Filtering](/categories/search)

loyaltycorp/search
==================

Search functionality provided by elastic search

v2.1.7(6y ago)03674[5 PRs](https://github.com/loyaltycorp/search/pulls)2BSD-3-ClausePHPPHP >=7.3CI failing

Since Apr 10Pushed 5y ago18 watchersCompare

[ Source](https://github.com/loyaltycorp/search)[ Packagist](https://packagist.org/packages/loyaltycorp/search)[ RSS](/packages/loyaltycorp-search/feed)WikiDiscussions master Synced 2d ago

READMEChangelog (1)Dependencies (20)Versions (39)Used By (2)

Search
======

[](#search)

The goals of this search package are to provide common functionality that enables creating and maintaining Elasticsearch search indices for an application.

It is up to the application to provide implementations of the `SearchHandlerInterface` (for simple search indices that the package will ensure are created) and `TransformableSearchHandlerInterface`(for indices that will react to changes to entities in external systems and transform those entities into search documents to be indexed).

An example implementation of both is provided.

Overview
--------

[](#overview)

This package provides multiple parts to enable easy search.

- There are index management commands provided that allow for reindexing without destroying the previous indices.
- Command options that will only reindex when the index mappings have changed (not yet implemented PYMT-1690)
- The Lumen service provider will auto discover any services tagged with `search_handler` and will use those discovered handlers to create and manage indices in Elasticsearch.
- The Lumen bridge providers a listener that will react to any Doctrine entity changes through the use of EasyEntityChange.
- The search handler interfaces provide multiple options for implementation depending on the application requirements.

Theory of Operation
-------------------

[](#theory-of-operation)

The primary and default implementation of this package sets up a listener that will react to any entity changes inside Doctrine and dispatch jobs for re-indexing those entities based on Search Handlers that are interested in specific changes.

Each application Search Handler will define an array of `ChangeSubscription` DTOs that describe the entities and relevant properties that should trigger the reindexing of a document.

The package will handle batching search updates into multiple jobs for handling, and pass a `ObjectForChange` DTO to the application Search Handler that describes an object that has changed - either the object was updated or deleted. It is then up to the Search Handler to return a `DocumentAction` DTO that describes what should happen to the Elasticsearch document.

### Lifecycle - Index management

[](#lifecycle---index-management)

When an application is initially created or deployed, the indices **must** be created before the application writes to Elasticsearch. Elasticsearch will eagerly create indices which is a behavior we dont want- so before the application accepts requests a migration/search setup process must run.

Following an imaginary index `transactions` through the following process:

```
# This command will create initial indices that are suffixed with the current date, and add an alias
# for each one that is suffixed with _new. No aliases exist at the root at this time.
#
# The system creates a `transactions_20200102121314` and a `transactions_new` alias that points to
# the date suffixed index.
$ ./artisan search:index:create

# This command fills the _new aliases with all document data for any search handlers that implement
# the TransformableSearchHandlerInterface. This command has options for synchronously filling or
# creating jobs to fill with workers.
#
# The system fills all data from the `getFillIterable` method on the TransactionSearchHandler. The
# index is still not live at this point.
$ ./artisan search:index:fill

# This command will atomically swap any root (live) aliases for any indices suffixed with _new that
# have had data populated. After this command is run, the application has been switched to the new
# indexes.
#
# The system sees that `transactions_new` (which points to `transactions_20200102121314`) has data
# in it, and atomically swaps `transactions` (which currently points to
# `transactions_20191212121212`) to now point to `transactions_20200102121314`. All index changes
# occur at the same time and if any fail to swap, they all fail.
$ ./artisan search:index:live

# This command cleans up any old aliases/indices that are no longer required.
#
# The `transactions_2019121212` index is removed.
$ ./artisan search:index:clean
```

### Lifecycle - reacting to Doctrine changes

[](#lifecycle---reacting-to-doctrine-changes)

This package listens for `EntityChange` events from the EasyEntityChange package. The `EntityUpdateWorker` converts these events into `ObjectForChange` DTOs that are then processed against the Search Handler subscriptions to find any intersections.

Once any intersections are found, the work is batched and dispatched as jobs for workers to process as required.

Example Search Handler
----------------------

[](#example-search-handler)

The below example is verbose, and contains code that would normally be placed inside an abstract search handler, to show the expectations of an implementation of the `TransformableSearchHandlerInterface`.

```