Skip to content
New issue

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

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

Already on GitHub? # to your account

@Query support Slice and Page #1760

Open
guodage opened this issue Apr 3, 2024 · 4 comments
Open

@Query support Slice and Page #1760

guodage opened this issue Apr 3, 2024 · 4 comments
Assignees
Labels
status: pending-design-work Needs design work before any code can be developed status: waiting-for-triage An issue we've not yet triaged

Comments

@guodage
Copy link

guodage commented Apr 3, 2024

I know PartTreeJdbcQuery support Slice/Page since #952, but I need use @Query for customized sql and Pageable in parameter when my scenes of query is complicated.

like this:

@Query("a long sql")
Page<Long> findPage(Pageable pageable);

I had forked from 3.0.12 and write some code to implement this in StringBasedJdbcQuery.
see 8btc-OnePiece@32b231f

I'm looking forward to any feedback, and confirm is there any guys need it or PR.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Apr 3, 2024
@mp911de
Copy link
Member

mp911de commented Apr 3, 2024

Pagination support for string-based queries requires either a provided count-query or would require SQL parsing. Either one isn't great, especially for more complex queries.

We aren't exactly keen for having a parser to rewrite queries so most likely, we would require a user-provided count-query.

@guodage
Copy link
Author

guodage commented Apr 7, 2024

My 100% page sqls are working well by rewrite count queries. Are there scenarios that can't be solved by this?

@schauder
Copy link
Contributor

From a quick look at your proposal I see problems with:

  • Nested selects especially with WITH clause.
  • Selects that contain String expressions that look like parts ofSQL statements
  • Same for column names or aliases
  • Selects that use GROUP BY
  • Different dialects requiring different variants of LIMIT clauses
  • Analytic functions utilizing ORDER BY
  • Statements already containing a LIMIT clause.

Again that are just the problems I found with a quick glance.
Painful experience with Spring Data JPA demonstrates that it is difficult to parse SQL sufficiently to do the required substitutions.

I wonder if we can come up with a way where the user provides the correct spots to inject the count and limit clauses.

@schauder schauder added the status: pending-design-work Needs design work before any code can be developed label Apr 11, 2024
@mp911de
Copy link
Member

mp911de commented Apr 12, 2024

For the time being, would we be able to wrap the query with an outer query like SELECT * FROM (<the inner select>) LIMIT … OFFSET … and require a provided count query?

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
status: pending-design-work Needs design work before any code can be developed status: waiting-for-triage An issue we've not yet triaged
Projects
None yet
Development

No branches or pull requests

4 participants