Added native query adapter

[Nek-]

No description provided.

[pablodip]

Could anyone related with DoctrineORM review this? CC/ @stof :)

[sstok]

This will fail when you have a sub-query in the SELECT part.

[stof]

This will fail in a lot of case actually. And the implementation forces to apply this even when providing a custom modifier, meaning there is no way to get rid of this broken implementation.

[Nek-]

At first the method countQueryBuilder was originally called on the else statement of this if https://github.com/whiteoctober/Pagerfanta/pull/167/files#diff-47292a5a239d0185dbe662f2f1b0ed81R70 .

But then I wrote the test and I noticed that having the result set mapping that corresponds to the count is more than useful. That's why I changed it to make it like that.

[sampart]

@Nek-, you've explained why you'd like the countQueryBuilder method to always be called (even if a modifier is provided), so thank you for that, but I'm not sure you've addressed @stof's concerns that the implentnation of that method will break in a lot of cases.

[Nek-]

The best answer I can give here is the detection of too complex queries and throw an exception for these cases. Otherwise good thing to do is to build an SQL analyzer.. :')

[Nek-]

Updated, ping @stof

[Gemorroj]

any updates?

[astronati]

@Nek- @stof Any update?
I'm having the same need in order to use ResultSetMappingBuilder

[stof]

I'm not maintainer of this library

[Nek-]

Not either. Maintainer edit enabled.

[sampart]

Thanks for your contributions, @Nek-, and for your review work, @stof.

I don't have the Doctrine knowledge of someone like @stof, but there were a couple of comments from the original review which didn't look like they'd be addressed (or only partially addressed). I've added comments in the relevant thread above to show what I think's needed.

@stof would you be happy to re-review if @Nek- does address your original concerns? As I say, you have more knowledge in this area than I do!

Thanks again both.