[hotfix]Fix the incorrent paramater transmission of PageNum and PageSize

[zhangwl9]

Why are the changes needed?

Close #xxx.

Brief change log

We need to to transmit parameters of pageNum and pageSize in 'PageHelper#startPage' and the TableMetaMapper#selectTableRuntimesForOptimizerGroup,OptimizingMapper#selectOptimizingProcesses.

We correct the inconsistent problem.

How was this patch tested?

• Add some test cases that check the changes thoroughly including negative and positive cases if possible

• Add screenshots for manual tests if appropriate

• Run test locally before making a pull request

Documentation

• Does this pull request introduce a new feature? (yes / no)
• If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

[zhangwl9]

@klion26 @czy006 Could you please take a look at this when you're free, thanks

[klion26]

@zhangwl9 thanks for the contribution, the change here LGTM.

As there was some ut want to cover the logic, so could you please help to check

1. if the logic here in the master is right or not(if the code logic in the master branch can give the right result, maybe it is because the parameter in PageHelper.startPage(pageNumber, limit, true) -- line 517 has a higher priority than the parameter in the mapper)
2. if the logic here in the master is wrong, could you please help to enhance the exist ut to cover the logic

[baiyangtx]

After introducing github.PageHelper, do we still need to pass the pageNumber and limit parameters to the mapper?

It seems that these two parameters are not required in the process of constructing SQL.

[zhangwl9]

@zhangwl9 thanks for the contribution, the change here LGTM.

As there was some ut want to cover the logic, so could you please help to check

1. if the logic here in the master is right or not(if the code logic in the master branch can give the right result, maybe it is because the parameter in PageHelper.startPage(pageNumber, limit, true) -- line 517 has a higher priority than the parameter in the mapper)
2. if the logic here in the master is wrong, could you please help to enhance the exist ut to cover the logic

@klion26 Thank you very much for your advice. I have tested and found the following:

1. The parameter (pageNumber,limit) in PageHelper.startPage(pageNumber, limit, true) -- line 517 has a higher priority than the parameter(pageNum, pageSize) in the mapper, as shown in figure
   

2. When building the mapper's SQL statement, if the parameters pageNum and pageSize are removed, amoro displays normally, as shown in the figure.
   

Therefore, pageNum and pageSize are not needed during SQL construction. I have already fixed it.

3. Two unit tests involving mappers: TestIcebergServerTableDescriptor#testOptimizingPorcess and TestDefaultOptimizingService#testGetRuntimes can both cover the results of PageHelper and PageInfo, therefore, no new unit tests need to be added.

[zhangwl9]

After introducing github.PageHelper, do we still need to pass the pageNumber and limit parameters to the mapper?

It seems that these two parameters are not required in the process of constructing SQL.
@baiyangtx Thank you very much for your advice. You are right. I have fix it.

[klion26]

Thanks for the fix, LGTM

[klion26]

@zhangwl9 Seems there are some tests failed, could you please help to check it, thanks.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 27.48%. Comparing base (243d289) to head (324f009).
Report is 15 commits behind head on master.

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #3343      +/-   ##
============================================
+ Coverage     21.59%   27.48%   +5.89%     
- Complexity     2309     3511    +1202     
============================================
  Files           426      593     +167     
  Lines         39719    48303    +8584     
  Branches       5624     6233     +609     
============================================
+ Hits           8577    13278    +4701     
- Misses        30414    34092    +3678     
- Partials        728      933     +205     

Flag	Coverage Δ
core	27.48% <ø> (?)
trino	?

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[czy006]

LGTM