Support for Paginator

[jproffitt3ge]

Right now the EntitySpecificationRepository::match method builds and executes a query directly. There is no way I can see to implement Doctrines Paginator for paginating complex queries. Would it break any principles to add a third "paginate" boolean parameter to the match method that wraps the query in a Paginator before execution, or to add a second "getPaginator" method to the EntitySpecificationRepository that returns a Paginator rather than results?

[Nyholm]

I've not considered that issue. Thank you.

I've been doing some thinking on this issue the last week but I have not come up with any good generic solution. I don't believe adding a third parameter is a good solution because I don't want to add a fourth parameter when the other feature X comes around.

I was thinking of refactor EntitySpecificationRepositoryTrait::match somehow. But does only contain a few lines of code...

$specification->modify($qb, $alias);
$query = $qb->where($specification->getFilter($qb, $alias))->getQuery();

if ($modifier !== null) {
    $modifier->modify($query);
}

I would suggest you to write your own EntitySpecificationRepository and implement your version of match there.

[jproffitt3ge]

How I handled this problem was I created a second method "getPaginator" to
the entity repository as you suggested, which takes the same parameters as
"match". To avoid repetition I moved the query building out to a protected
"getSpecificationQuery" method.

Justin Proffitt
Lead Web Programmer
719.964.7350 voice/text
LEGAL CONFIDENTIAL: All information in this e-mail and in any attachment
contains information which is legally privileged. It is provided only for
the attention and use of the named recipient. If you are not the intended
recipient, you are not authorized to retain, disclose, copy or distribute
the message and/or any of its attachments.

On Tue, Mar 17, 2015 at 5:54 AM, Tobias Nyholm notifications@github.com
wrote:

I've not considered that issue. Thank you.

I've been doing some thinking on this issue the last week but I have not
come up with any good generic solution. I don't believe adding a third
parameter is a good solution because I don't want to add a fourth parameter
when the other feature X comes around.

I was thinking of refactor EntitySpecificationRepositoryTrait::match
somehow. But does only contain a few lines of code...

$specification->modify($qb, $alias);$query = $qb->where($specification->getFilter($qb, $alias))->getQuery();if ($modifier !== null) { $modifier->modify($query);}

I would suggest you to write your own EntitySpecificationRepository and
implement your version of match there.

—
Reply to this email directly or view it on GitHub
#85 (comment)
.

[Nyholm]

What if match() retured the Query instead of executing it?

[drewclauson]

Would it be overkill to let match() continue to execute the query but have a different function return the Query or QueryBuilder instead? (I've been using the match quite a bit in code that I plan to deploy to production but obviously refactoring to execute the query isn't that crazy.) I haven't used the Paginator but could see it being useful at some point.

[rikbruil]

FYI: I think the fix for this issue has just been merged to master :)

Instead of doing $results = $repo->match($spec); you can now also do $query = $repo->getQuery($spec); which solves this issue. You can now ask for a Query object if you need it or use match if you just want results.