-
Notifications
You must be signed in to change notification settings - Fork 59
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
Introduce specialized expression types for easier JPA Criteria querying #519
Comments
That's a good idea @beikov. How about prototyping your proposal as a pull req? |
Hello, i like the idea. :) Cheers |
beikov
added a commit
to beikov/persistence
that referenced
this issue
Sep 1, 2023
… Criteria querying
beikov
added a commit
to beikov/persistence
that referenced
this issue
Sep 1, 2023
… Criteria querying
beikov
added a commit
to beikov/persistence
that referenced
this issue
Sep 19, 2023
… Criteria querying
beikov
added a commit
to beikov/persistence
that referenced
this issue
Sep 19, 2023
… Criteria querying
beikov
added a commit
to beikov/persistence
that referenced
this issue
Sep 19, 2023
beikov
added a commit
to beikov/persistence
that referenced
this issue
Sep 19, 2023
… Criteria querying
beikov
added a commit
to beikov/persistence
that referenced
this issue
Sep 19, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I don't know how feasible this is, but this idea just came to mind and I wanted to share it here.
What if we introduced special
Attribute
,Expression
andPath
types for certain known types to make it easier to construct predicates and/or functions. I propose the following additions:NumberAttribute
,NumberExpression
andNumberPath
when the type extendsNumber
StringAttribute
,StringExpression
andStringPath
when the type extendsString
TemporalAttribute
,TemporalExpression
andTemporalPath
when the type extendsTemporal
ComparableAttribute
,ComparableExpression
andComparablePath
when the type extendsComparable
Then we add some overloads to
Path
:And all of a sudden we could write nicer queries that don't involve calling methods on the
CriteriaBuilder
e.g.:instead of
Of course this is just a simple example, but I think that the major criticism against the JPA Criteria API is that it is hard to write and read, which I think is mostly due to the need of involving the
CriteriaBuilder
everywhere.I know that there is a small "type explosion" here i.e. 3 classes for every type we want to add decent support for, but I think it's worth it and that the number of supported types will stay in the single digit realm :)
The text was updated successfully, but these errors were encountered: