zhangwl9 commented on PR #3343:
URL: https://github.com/apache/amoro/pull/3343#issuecomment-2522615161

   > @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
   
   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 
   
![image](https://github.com/user-attachments/assets/d7662731-e1d9-4fcb-9dc8-6b87e98e3abf)
   
   
   2) When building the mapper's SQL statement, if the parameters pageNum and 
pageSize are removed, amoro displays normally, as shown in the figure.
   
![image](https://github.com/user-attachments/assets/8700505d-706c-4eb7-8c31-13f053d67ba8)
   
   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.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to