Download the PHP package mongerinc/search-request without Composer

SearchRequest

This library provides a set of classes that help represent requests for complex data and provides a way to convert requests to and from a standard JSON format. If you have interfaces with tons of parameters ($filters, $groupings, $page, $rowsPerPage, etc.), or if you're just looking for a standard way to communicate complex requests to other apps without racking your brain over how to represent this data in JSON, you will like this library.

• Version: 5.6.2

Table of contents

• Installation
• Usage
  • JSON
  • Selection
  • Sorting
  • Grouping
  • Pagination
  • Filtering
  • Faceting
  • Field Substitution
• Examples

Installation

Install SearchRequest via composer by adding the following to the require block in your composer.json file:

Usage

When creating a SearchRequest from scratch, you first need to instantiate a request:

As a starting point, each search request has no sorts, no filters, and no groupings. Pagination starts at page 1 and by default there is a limit of 10 rows per page.

JSON

Using the toJson() method, each SearchRequest instance can be compiled into a JSON string that you can use to communicate across application boundaries.

Likewise, you can build a new SearchRequest instance using a JSON string that was compiled by a SearchRequest instance.

Selection

The most common method of setting selections on the request is by using the select() method which overrides any existing selects:

If you want to add to existing selects, you can call the addSelect() method instead. You can chain this method:

Retrieving the set of selects is done by the getSelects() method.

Sorting

The most common method of sorting the request is by using the sort() method which overrides any existing sorts:

The first parameter in any sort call is the string field and the second parameter is the sort direction which is limited to asc and desc.

If you want to create a request with multiple sorts, you can call the addSort() method instead. You can chain this method:

If you want to retrieve the sorts, you can either call the getSort() method to get the primary sort, or you can call getSorts() to get the array of all sorts. Each sort is represented by a Sort instance where you can ask for the field and the direction:

Grouping

Grouping a SearchRequest can be done using the groupBy() method. The groupBy() method takes either a string or an array of strings as an input. The method can also be chained.

Retrieving the set of groups is done by the getGroups() method.

Pagination

Creating a new SearchRequest defaults to page 1 and a limit of 10 rows per page. If you want to modify this, you can call the page() and limit() methods:

If you want to simply go to the next page, you can call the nextPage() method and it will increment the current page by 1.

Retrieving the page and limit is done by the methods getPage() and getLimit():

Alternatively, you can call getSkip() to avoid doing the calculation above.

If you want to ignore the pagination for a request, you can call the unlimited() or all() methods.

The unlimited feature is only a flag. Your database query applier must check for this with the isUnlimited() method to support this feature.

Filtering

Filtering a SearchRequest can be done using the where() method. An operator can be provided as the second argument where the possible types are =, >, >=, <, <=, !=, in, not in, like, not like, regex, not regex, exists, not exists, between, and not between. If no operator is provided, it is assumed to be =.

Each of the word-like operators (in, like, regex,exists,between`) has a set of four companion helper methods. These follow this general format:

Reading filters from the search request can be done using the getFilters() method:

You can also call getFilter($field) or getFilterValue($field) on the SearchRequest or FilterSet to get the Filter/value respectively of the first filter that matches that field name. This is useful if your filters are relatively simple and you only expect one value for each field name.

More complex filtering can be accomplished by using nested conditions. Assuming you wanted to make a request representing the following pseudo-SQL conditional statement:

...you would do the following...

When reading a complex set of conditionals back from the SearchRequest, there are several important concepts to understand:

1. Each nesting layer (including the top layer) is represented by a FilterSet. A FilterSet has a boolean (and/or) and can be comprised of any combination of Filter and FilterSet objects. These objects are provided in the order they were entered.
2. A Filter object represents a field, value, and conditional operator along with a boolean (and/or).

Since the nesting of conditionals is theoretically infinite, you may want to implement a recursive function to apply the request to the library of your choice (like a database query builder). An example of this can be seen in the /examples directory.

It's also possible to remove filters by name:

Faceting

Faceting (i.e. getting attribute values and their counts) a SearchRequest can be done like this:

This will create a facet for someField and, unlike other methods, returns a Facet instance instead of the SearchRequest. You can also create multiple facets at once:

And you can get facets either one at a time by field name (will only return the first match):

Or all at once:

Sorting a facet's results can be done either by count or value (the default) and a direction.

The minimum number of values a facet field must have in order to be returned in the result set is 1.

Filters that exist for the facet's field are by default excluded from consideration when building the facet results.

A facet can also be paginated just like the search request and with the same default values:

Field Substitution

When making search requests, you often want to keep the specifics of a data storage schema hidden from the rest of your code base. For example, you may have a denormalized SQL field called category_name on your products table that on the way out gets formatted as:

So the rest of your system sees category.name as the field, but your SQL repository only understands category_name. This is where field substitution comes in handy:

You can also substitute many fields at once by passing in an array of original => substitution values:

Examples

At the root of this project there is an /examples directory that contains a few examples of how you would apply search requests to database queries. As this project was inspired by Laravel's query builder, one example shows how to leverage SearchRequest to apply complex parameter sets to it in a reusable way. Using the same approach, SearchRequest can be used to apply complex parameter sets to any library that needs them (e.g. MongoDB, Solr, etc.).