Morning,
I've have been getting along great with Content Distribution, however I've just tried to test it in terms of scalability and have encountered an issue.
I'm hoping I've got a bit of configuration missing somewhere but here is my set up -
* Standard view that filters by published state, content type (one type) and the content distribution published field
* The view returns full nodes
* It is a page view with a limit of 20 nodes per page, but no pager selected.
So a basic set up for content distribution, however when I test this by generating loads of nodes (approx 400), then trying to sync with a child site, the content sync attempts to pull all 400. It does not respect the 20 per page limit with only one page. I would have expected the view to only pull 20 nodes?
The view does work and will return as many nodes as it can before timing out.
Am I missing something on the child site, I could not see any extra configuration. Or is this a view.get services issue?
If someone else has mentioned this previously can someone link me up please as I could not find anything.
Thanks,
Luke
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | content_retrieverOffsetLimit.patch | 1.29 KB | luketsimmons |
| #2 | content_retriever.adminOffsetLimit.patch | 3.4 KB | luketsimmons |
Comments
Comment #1
luketsimmonsOK I've found the answer. In _content_retriever_get_view() we do not pass details such as $offset or $limit to the service "views.get", therefore the view only ever gets everything (i.e. limit = 0) for the content distribution view.
We can make this possible by adding in some form fields for the view set up to save the values. This means the admin user can determine the result size per child (retriever) site?
I'll sort out a patch post it up for anyone who is interested.
Thanks,
Luke
Comment #2
luketsimmonsHi,
Please find attached two patches for adding the extra options for setting an items per page limit and offset within the content distribution view. Like the other settings for display and arguments, the default values will be obtained from the remote server first, then you can set your own.
This means you can set how many nodes you want to distribute from the view. Currently $limit is not set for the views.get service in Content Retriever, so all nodes from the view will be collected. This could be a large number and this will cause a time out.
Usual practice of saving the patches locally inside the content_retriever module in the content_distribution/modules folder and run the usual patch command (patch < filename.patch). Then go to the "View settings > Arguments" section in Content Retriever to set the values.
Can someone let know if there are any problems with the patches please? I've tested it all and it works as expected for me.
Thanks,
Luke
Comment #3
joachim commentedIsn't the flaw rather that views.get should only return the pager limit?
In views_service_get():
Or does the view building code not take pager limits into account?
I'd rather fix that here if possible rather than add form options.
Comment #4
luketsimmonsHi joachim,
I thought that to start with, but yes in the content_retriever module we are not passing any values to views.get for offset or limit in the view building code, so the default value for $limit is 0, which Views wise means you get everything, it would ignore any pager value since page one would have everything on there?
I agree I think there is an issue with the views.get method too as it always sets a pager if you pass a page limit, though some views will want to apply an items per page limit but only display one page.
But what I have added via the patch will at least give you ability to pass the $offset and $limit to views.get. When loading the form in the "view settings" we get the values that have been set on the distributor view for offset and limit as default values, so if the user just submits this they at least get the pager limits they expect from the view.
Thanks,
Luke