entity_name.repository
For products this then would be product.repository
, so let's do this.ReadingData
and applied the repository as a constructor parameter. If you want to fetch data for another entity, just switch the id
in the services.xml
to whatever repository you need, e.g. order.repository
for orders.readData
on your previously created service. That's it already. It will read some products without any special filtering. The result of the search
method will be an instance of an EntitySearchResult
, which then contains the collection of products.$context
is usually passed through to your method, starting from a controller or an event.$myId
or it will return null
, if no product was found with that ID. But how does that work now?Criteria
object accepts an array of IDs to search for as a constructor parameter. This means, that you could apply more than just one ID here.search
method will then return a EntitySearchResult
, which contains the according entity collection of all products. Even though just one product can be matched here, the method will always return a collection, which then contains your single product. Therefore we're calling first()
to get the actual entity, and not the collection as a return.Criteria
object, such as an EqualsFilter
, which accepts a field name and the value to search for. You can find the EqualsFilter
here: Shopware\Core\Framework\DataAbstractionLayer\Search\Filter\EqualsFilter
Example name
and return an EntitySearchResult
containing all matched products. Since the EntitySearchResult
is extending the EntityCollection
, which is iterable, you could just iterate over the results using a foreach
.ProductDefinition
for this example.OrFilter
or the AndFilter
, or the NandFilter
, etc.id
OR the mentioned name
. The OrFilter
can be found here: Shopware\Core\Framework\DataAbstractionLayer\Search\Filter\OrFilter
.Example product
, but also return the total amount of products available.addPostFilter
instead of addFilter
:EqualsFilter
, which is the SQL equivalent of WHERE fieldX = valueX
. You can find all other filters either on GitHub or with an explanation in our filters reference.getAssociation
instead, which basically returns its own Criteria
object, on which you can apply a filter.getAssociation
here now instead of addAssociation
. Also you need the RangeFilter
, which can be found here: Shopware\Core\Framework\DataAbstractionLayer\Search\Filter\RangeFilter
productReview
associations. The latter will just return your product, if it has at least one matching review.ManyToMany
association comes with a mapping entity, such as the ProductCategoryDefinition
. It's important to know, that you cannot read those mapping entities using the search()
method.search
. It will suffice to use searchIds
instead, which will return the IDs - and that's all there is in a mapping entity.addAggregation
method on the Criteria
object. Let's create an example aggregation, that returns the average rating for a product:first()
call, because we do not need the entity itself but the EntitySearchResult
here instead. The AvgAggregation
class can be found here: Shopware\Core\Framework\DataAbstractionLayer\Search\Aggregation\Metric\AvgAggregation
setLimit
method with your desired limit as parameter. Little spoiler: It's the same for the offset!createdAt
field, so the result becomes a lot more predictable. The FieldSorting
can be found here: Shopware\Core\Framework\DataAbstractionLayer\Search\Sorting\FieldSorting
.RepositoryIterator
will return a batch of data, which size you can define, with each iteration. Just be sure to not use it unnecessarily, since it will create a new database request with each iteration, which is not needed for smaller chunks of data.while
loop. This way, $result
will not cause a "memory exhausted" error and you can handle huge amounts of data this way.RepositoryIterator
, make sure that the Criteria
uses a sorting which is deterministic.manufacturerNumber
alone could cause this issue, because several products can have the same manufacturerNumber
, so there's several correct orderings of those products. On the other hand, because each product is guaranteed to have a unique ID, sorting by ID is an easy way to mitigate this issue: