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

Spring 3.1 EntitySpecification + Pageable + EntityGraph Pages In-Memory #3223

Closed
thejeff77 opened this issue Nov 8, 2023 · 1 comment
Closed
Labels
status: duplicate A duplicate of another issue

Comments

@thejeff77
Copy link

thejeff77 commented Nov 8, 2023

This is mostly a follow up for this #3206 since it was closed without really engaging in discussion, and I have feedback / follow up for this. I'm guessing I have to issue a new issue for follow ups when its immediately closed in cases like this... since its not my intention of going away just yet. Sorry to be annoying.

To quote my reply:

=========
@mp911de I guess I'm wondering why spring data won't use setMaxResults alone when the page request is for page number 0 (I.E. the first page), and not page in-memory for this case.

This would allow a limit to be set to a query that isn't technically paging yet, as page isn't > 0.

I'm pretty sure its not possible to set a queryhint dynamically in spring data, is it?. If not, setting setMaxResults on this dynamically clearly isn't possible, but I could possibly do it with a static hard coded value that is in the annotation. Am I right or am I missing anything?

It seems like this might be better as a bug report / optimization feature request to allow limit queries dynamically in these cases where a page request represents a limit query and not a paging query (I.E. Page number = 0)

Am I making sense or am I missing something?

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

mp911de commented Nov 9, 2023

Thanks for reaching out. Let's continue the discussion in the original ticket. Closing a ticket isn't a termination of the discussion, rather, that the ticket isn't actionable in its current form. Adding more details can change its state. Therefore, to not create duplicate threads, I'm closing this one and respond to your comment at #3206 (comment).

@mp911de mp911de closed this as completed Nov 9, 2023
@mp911de mp911de added status: duplicate A duplicate of another issue and removed status: waiting-for-triage An issue we've not yet triaged labels Nov 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: duplicate A duplicate of another issue
Projects
None yet
Development

No branches or pull requests

3 participants