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

Update order modifier queries #3479

Open
wants to merge 33 commits into
base: release/T25.imp
Choose a base branch
from

Conversation

JPry
Copy link
Contributor

@JPry JPry commented Jan 10, 2025

🎫 Ticket

ET-2268

🗒️ Description

This PR makes the following changes to the order modifier database queries:

  1. It makes correct use of the QueryBuilder objects to create the queries instead of relying on direct strings
  2. Some of the main queires now allow for more parameters, including:
  • limit - limit the number of results returned, with a default of 10.
  • order - specify ordering ASC or DESC.
  • orderby - specify what column to order the results by. Defaults to id.
  • offset - specify how many results to skip before returning results.
  • page - specify what page of results to retrieve. Overrides offset.
  • status - specify an array of statuses for the results
  1. The Fees admin table uses the pagination features of the updated queries
  2. There are tests in place to ensure the correct results are provided.

🎥 Artifacts

✔️ Checklist

  • Ran npm run changelog to add changelog file(s). More info here
  • Code is covered by NEW wpunit or integration tests.
  • Code is covered by EXISTING wpunit or integration tests.
  • Are all the required tests passing?
  • Automated code review comments are addressed.
  • Have you added Artifacts?
  • Check the base branch for your PR.
  • Add your PR to the project board for the release.

@JPry JPry self-assigned this Jan 10, 2025
@JPry JPry requested a review from Camwyn January 10, 2025 04:57
* @test
* @return void
*/
public function should_find_all_fees() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we sure that the most crucial functionality introduced is covered by this test case ? If not, could we become please ?

Copy link
Member

@Camwyn Camwyn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dimi brought up some other things in Slack, so I'm not going to cover that here.

// Set the items for the table.
$this->items = $data;
// Get the total number of items.
$total_items = $this->modifier->find_count_by_search( [ 'search_term' => $search ] );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This does a second query - can't we just count the results above (pre-limit)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can't we just count the results above (pre-limit)?

Doing that, we'd need to run a query without the limit in place. Otherwise the limit will mean we only get the count according to the limit.

I did some research into the counting. I had intended to use SQL_CALC_FOUND_ROWS (the way WP_Query does it), and what I found was that it was less efficient than doing a second COUNT() query for the same results (minus the limits).

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

Successfully merging this pull request may close these issues.

3 participants