Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

implement paging functions #13

Open
j-ro opened this issue Aug 8, 2015 · 4 comments
Open

implement paging functions #13

j-ro opened this issue Aug 8, 2015 · 4 comments

Comments

@j-ro
Copy link

j-ro commented Aug 8, 2015

This can be implemented after some of the other stuff, but tor the entire API, you might want to implement the paging functions as described here:

http://opensupporter.github.io/osdi-docs/#collections-and-navigation

Right now it seems you return all contacts in the Civi system with going to the people endpoint. While there aren't many, this probably works fine. Once you have thousands, or tens of thousands, or hundreds of thousands, that's going to cause extremely slow performance. Implementing paging and navigation will keep things fast.

The way we've done it, we've set the default max page size to 25. Folks can request less than that, but we've also set the overall max page size to 25 to keep things fast. You might want to talk with Eileen about what the defaults and overall max should be for a civi system.

@eileenmcnaughton
Copy link

So, the relevant link regarding the CiviCRM api is http://wiki.civicrm.org/confluence/display/CRMDOC/Using+the+API
which covers how you do paging (offset & limit) with CiviCRM - I think you are currently just retrieving the 25 default limit? Or did you change that?

I presume you need to map the CiviCRM format for specifying paging type stuff to the OSDI format?

@j-ro
Copy link
Author

j-ro commented Aug 9, 2015

Right now, the OSDI endpoint seems to be retrieving all responses. I get 236 here:

http://camus.fuzion.co.nz/hal-browser/browser.html#/sites/default/ext/osdi/api/v3/People/index.php

So yeah, mapping those paging and navigation functions and adding links to the OSDI response for previous and next should do it.

@anuditverma
Copy link
Owner

Jason, I agree we don't want to crash our servers or decrease their performance. So I believe paging and navigation is also provided as a part of HAL-spec (as in clickable buttons for for accessing next & prev pages each having a definite set per_page value) so if I include a function for handling this functionality then HAL-browser would show up the navigation buttons. OR this can be done if I pass a variable in the url from the AEP to navigate to the per page result and a button for changing page number value in the url to navigate between pages. Right now I am more positive towards the latter method, is there any other way that I may have missed ?

@j-ro
Copy link
Author

j-ro commented Aug 10, 2015

You'll want to do navigation as its defined in the osdi spec linked above. So links with a specific label. What the url is can be anything, the label is the important part.

For the per page limit and page number url arguments I believe the osdi spec says what arguments must be used.

On Aug 9, 2015, at 6:42 PM, Anudit Verma [email protected] wrote:

Jason, I agree we don't want to crash our servers or decrease their performance. So I believe paging and navigation is also provided as a part of HAL-spec (as in clickable buttons for for accessing next & prev pages each having a definite set per_page value) so if I include a function for handling this functionality then HAL-browser would show up the navigation buttons. OR this can be done if I pass a variable in the url from the AEP to navigate to the per page result and a button for changing page number value in the url to navigate between pages. Right now I am more positive towards the latter method, is there any other way that I may have missed ?


Reply to this email directly or view it on GitHub.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants