Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Override .max_nb_records #22
NACK - this basically breaks all deployments of the plugin. I'm not even sure that for 20k+ records, the plugin pagination APIs still work after this change.
My comment in killbill/killbill-plugin-framework-ruby#67 regarding the 20k number was an example of how Kill Bill core handles very large datasets (e.g. account pagination APIs). My suggestion was to take a similar approach for plugins, but the code needs to be written (it's in a complete different codepath).
@pierre I did not see anything broken by doing this.
As I commented above, setting
If we look at the codes:
Besides that, I think the pagination would be fine cause it actually works with
Could you please give more details about the pagination failure you mentioned?
I might miss something here, but I don't think a fixed
And for a real working payment system, 20k+ responses would be easy to exceed in a short period. So I still prefer reducing 2 or at least 1 query for every search request to providing a max record number which is only accurate in 20k. Because if the search volume is high the query time matters otherwise if the search volume is low the max number does not matter.
To finalize the change, I'm fine to follow your suggestion if you insist.
Maybe, to be tested (all of that logic is delegated to DataTables, and it has been a while since I touched this integration). Regardless, the legend would be wrong/confusing.
Agreed, but we have lots of Kill Bill deployments nowadays at a much smaller scale (and typical QA/test environments don't have that many rows).
I'm all in favor to optimize the large scale deployment, but I don't want to compromise on the generic use-case (a brand new deployment would be broken out of the box).
My initial suggestion on the other ticket was to do something similar that Kill Bill core does today, but in the plugin-framework-ruby (that way, you have it for free for CyberSource and PayPal). If you prefer fixing it only for Orbital for now, I'm fine too.
Were you able to confirm it solves the performance problem (no extra index required / no need to tweak the generated SQL query)?
Also, before I release, can you verify integration tests pass against our sandbox (we don't have them enabled in CI)? Make sure also to verify the plugin works fine in your Kill Bill deployment (I'm fuzzy if the lambda syntax is already compatible with your version of Kill Bill).