To provide you (a Silverstripe developer) with interfaces for search querying that do not change, even when you switch between different search service providers (EG: Elastic, Algolia, Silverstripe Search).
To deliver on our purpose, the way that you perform filtering, faceting, and certainly the way that you display results, is very likely going to change. We hope that the learning curve is reasonable, and that the majority of developer interactions with this code is intuative (once you understand the mentality behind it).
You will not be able to perform any sort of "raw filtering" or "raw querying" with service specific formats, as that would not meet the purpose of this module - which is to use a common interface that will allow you to easily switch between services.
Note: this module does not function without an integration module
If you want to install this module for developing your own integration module, then you can install it with:
composer require "silverstripe/silverstripe-discoverer"
If you are planning to search through a page and controller, then you might also want to consider using Silverstripe Discoverer > Search UI
Whether or not certain features are supported by this module. Noting that different search providers often do things in different ways, and often have different levels of support for features. This module attempts to provide a level of functionality that is commonly supported by many different services.
| Feature | Module support | Future module support | Rationale |
|---|---|---|---|
| Filters | Yes | Yes | You should (hopefully) be able to achieve any sort of nested filtering that you require. |
| Facets | Partial | Partial | Facet support differs hugely between search services. Current thinking is to try and limit what sort of Facet integrations we support (EG: no Geolocation) in the hopes that if you switch services in the future, you won't lose functionality. |
| Multi-search | No | If desired | Not supported by many search services. It wouldn't be unreasonable effort to add this functionality though. Plugin modules for services without mult-search could manually perform 2 searches and combine the results. |
| Query suggestions (aka auto-complete) | Yes | Yes | Query suggestions and Spelling suggestions are the same feature for some services, but a different feature for others. Discoverer treats them as different features with a common goal (providing some form of "suggestion") |
| Spelling suggestions (aka "did you mean") | Yes | Yes | Query suggestions and Spelling suggestions are the same feature for some services, but a different feature for others. Discoverer treats them as different features with a common goal (providing some form of "suggestion") |
| Click through logging | Yes | Yes | Supported in Elastic App Search, but not supported by many other Search Services (including Elasticsearch). This feature in particular is an example of the "silent treatment" that might be applied when a feature disappears between service providers. |
- Querying, filtering, faceting, etc, will now all be performed through interfaces that are provided by this module. There is no ability to perform (eg) "raw filtering", or "raw faceting", where you pass data that is in a specific format for a specific search service provider. This would break the purpose of this module, since if your search service provided changed, then your "raw filtering" would also likely break.
- This module does not assume that your search Documents relate to a
DataObject, as such, it is recommended that your search Documents contain all of the data required for you to build out search results without needing to query the application for any additional information. - When you perform a search, you will receive a
Resultobject that includes aPaginatedListofRecordobjects. TheRecordobjects will contain any/all information that you requested during your query, and this is how you will output info into your template. - Fields within your
Recordobjects will match the fields in your search index, but be converted to PascalCase, with abbreviations presented as (eg)Id,Url, etc. You can read more about this under Field convensions.
Additional documentation can also be found below:
- Simple usage
- Provides some basic code samples.
- Includes a bit more detail on how
ResultsandRecordswork.
- Detailed result handling
- Lots more information about
Results,Records, pagination, analytics.
- Lots more information about
- Detailed querying
- Lots more information about filters, facets, sorts, and (hopefully) everything else you need to know to perform whatever sort of search you require.
You're mostly free to use any field names you would like when configuring your data sources, however, there are
2 methods provided in our Record class that will effectively override any field that is made available under:
AnalyticsDataDecoratedLink