2

This issue is bugging me for some time now. To test it I just installed a fresh Apigility, set the db (PDO:mysql) and added a DB-Connected service. In the table I have 40+ records. When I make a GET collection request the response looks OK (with the default HAL content negotiation). Then I change the content negotiation to JSON. Now when I make a GET collection request my response contains only 10 elements.

So my question is: where do I set/change this limit?

Zsolt
  • 31
  • 3
  • Did you set a page size parameter somewhere? – Wilt Feb 09 '16 at 15:41
  • @Wilt Well... I thought that it somehow enforced the page size from the HAL settings, but that is set to 25 by default. Tried to change that but that didn't change the outcome, there are only 10 results showing up whatever the page size is set to. – Zsolt Feb 09 '16 at 17:03
  • I've run into this same problem. You'd think the plain JSON default would be unlimited results, but maybe they're concerned about unbounded queries ruining your performance. I may have to switch to using the HalJSON option just because of this. – Daniel Skarbek Apr 02 '17 at 22:40

3 Answers3

1

You can set the page size manually, like so:

 $paginator = $this->getAlbumTable()->fetchAll(true);

 // set the current page to what has been passed in query string, or to 1 if none set
 $paginator->setCurrentPageNumber((int) $this->params()->fromQuery('page', 1));

 // set the number of items per page to 10
 $paginator->setItemCountPerPage(10);

http://framework.zend.com/manual/current/en/tutorials/tutorial.pagination.html

Paul Roub
  • 36,322
  • 27
  • 84
  • 93
Hillus Hilbert
  • 11
  • 1
  • Please post in English. – Tunaki Apr 05 '16 at 12:45
  • The question is how to set this (or remove the limit) when working with the DB-Connected interface. The nice thing about this setup is that you don't have to write any custom code. You can do it all through the Apigility UI. It's great for quick prototype projects and such, but the limit to 10 results unnecessarily hampers that prototyping. – Daniel Skarbek Apr 02 '17 at 22:37
0

Could you please send the page_size, total_items part at the end of the json output?

it's like:

"page_count": 140002,
"page_size": 25,
"total_items": 3500035,
"page": 1
tkorkunckaya
  • 164
  • 3
  • 15
  • This is inlcuded only when the Content Negotiation is set to HAL (and then it shows the right data). But, as I pointed out in the question, the Content Negotiation is set to JSON therefore only the actual response data included in the JSON. The problem is that this response contains only 10 elements although there is no limit set anywhere, at least not by me. – Zsolt Feb 10 '16 at 09:57
0

This is not an ideal fix, because it requires you to go into the source code rather than using the page size given in the UI.

The collection class that is auto generated for you by the DB-Connected style derives off of Zend/Paginator/Paginator. This class defines the $defaultItemCountPerPage static protected member which is defaulted to 10. That's why you're only getting 10 results. If you open up the auto-generated collection class for your entity and add: protected static $defaultItemCountPerPage = 100; in the otherwise empty class, you will see that you now get up to 100 results in the response. You can look at other Paginator class variables and methods that you could replace in your derived class to get your desired behavior.

This is not an ideal solution. I'd prefer that the generated code automatically used the same configed page size that the HalJson strategy uses. Maybe I'll contribute a PR to change that. Or, maybe I'll just use the HalJson approach. It does seem like the better way to go. You should have some limit to how much data you load in from the DB at a time to not have an overly long running query or an overly large collection of data coming back you have to deal with. And, whatever limit you set, what do you do when you hit that limit? With the simple Json method, you can't ever get "page 2" of data. So, if you are going to work with some sizeable amount of data, it might be better to use HalJson on and then have some logic on the client side to grab pages of data at a time as needed. The returned JSON structure is a little more complicated, but not terribly so.

I'm probably in the same spot you are -- I'm trying to do a simple little api to play with while keeping everything simple and so I didn't want the client to have to deal with the other stuff in HalJson, but probably better to deal with that complexity and have a smooth way to page through data if you're going to use this with some real set of data. At least, that's the pep talk I'm giving myself right now. :-)

Daniel Skarbek
  • 554
  • 4
  • 14