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

[Use Case]: Statically specify First/Limit at dev time so that singular return type can be valid on methods #532

Open
2 of 4 tasks
njr-11 opened this issue Mar 8, 2024 · 6 comments · Fixed by #1027
Open
2 of 4 tasks
Labels
Milestone

Comments

@njr-11
Copy link
Contributor

njr-11 commented Mar 8, 2024

As a ...

  • Application user/user of the configuration itself
  • API user (application developer)
  • SPI user (container or runtime developer)
  • Specification implementer

I need to be able to ...

statically specify a limit at development time

Which enables me to ...

write a repository method with a singular return type (Optional<MyEntity> or MyEntity).

Additional information

This is currently only possible (and awkwardly so) with Query by Method Name.

To allow it with @Query and parameter based queries (@Find), we can add First (proposed by Gavin in #530 (comment))

@Find @First
@OrderBy(value = _Employee.SALARY, descending = true)
@OrderBy(value = _Employee.ID)
Optional<Employee> highestPaid(String jobTitle);

The value would default to 1.

Reminder to update recommendations in NonUniqueResultException once we have this.

This is being proposed for after Jakarta Data version 1.0.

@njr-11 njr-11 added the enhancement New feature or request label Mar 8, 2024
@njr-11 njr-11 added this to the Jakarta Data Future milestone Mar 8, 2024
@gavinking
Copy link
Contributor

@njr-11 @otaviojava do you think we should scope this for 1.1?

I think we should discuss it at least.

@njr-11
Copy link
Contributor Author

njr-11 commented Mar 20, 2025

@njr-11 @otaviojava do you think we should scope this for 1.1?

I think we should discuss it at least.

I agree with including it. It would be easy to add and is useful.

gavinking added a commit to gavinking/data that referenced this issue Mar 23, 2025
@gavinking gavinking linked a pull request Mar 23, 2025 that will close this issue
gavinking added a commit to gavinking/data that referenced this issue Mar 24, 2025
@njr-11 njr-11 modified the milestones: Jakarta Data Future, 1.1 Mar 25, 2025
@njr-11
Copy link
Contributor Author

njr-11 commented Mar 25, 2025

Reopening. TCK is still needed.

@njr-11 njr-11 reopened this Mar 25, 2025
@gavinking
Copy link
Contributor

@njr-11 I was wondering if it would be better to track the TCK work in the TCK issue, rather than leaving lots of issues open.

1 similar comment
@gavinking
Copy link
Contributor

@njr-11 I was wondering if it would be better to track the TCK work in the TCK issue, rather than leaving lots of issues open.

njr-11 added a commit to njr-11/data that referenced this issue Mar 25, 2025
… solution to NonUniqueResultException

Signed-off-by: Nathan Rauh <nathan.rauh@us.ibm.com>
@njr-11
Copy link
Contributor Author

njr-11 commented Mar 25, 2025

@njr-11 I was wondering if it would be better to track the TCK work in the TCK issue, rather than leaving lots of issues open.

That would be fine with me. It wasn't listed there, but I just added it. In the case of this particular issue, the API work wasn't actually done yet either because there is also the part in the issue description about updating the text of NonUniqueResultException. I just created #1031 to do that. After that, I think we can close this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants