Support Arithmetic function SIZE #626
Conversation
jbl428
requested review from
pickmoment,
huisam,
cj848 and
shouwn
as code owners
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## develop #626 +/- ##
===========================================
+ Coverage 66.40% 66.47% +0.06%
===========================================
Files 465 467 +2
Lines 4748 4760 +12
Branches 277 277
===========================================
+ Hits 3153 3164 +11
- Misses 1538 1539 +1
Partials 57 57 ☔ View full report in Codecov by Sentry. |
|
|
||
| @Internal | ||
| data class JpqlSize internal constructor( | ||
| val path: Path<*>, |
There was a problem hiding this comment.
I can not sure that this class should take Path or Expression
SIZE(collection_valued_path_expression)
There was a problem hiding this comment.
I think Path is a better fit than Expression, and I think we should limit the generic type of Path to Collection.
When I checked the Criteria API, it takes an Expression, but only takes into account the Path.
| @SinceJdsl("3.4.0") | ||
| fun <T : Any, V> size(expr: KProperty1<T, @Exact V>): Expression<Int> { | ||
| return Expressions.size(Paths.path(expr)) | ||
| } | ||
|
|
||
| /** | ||
| * Creates an expression that the number of elements of the collection. | ||
| */ | ||
| @SinceJdsl("3.4.0") | ||
| fun <T : Any> size(path: Pathable<T>): Expression<Int> { | ||
| return Expressions.size(path.toPath()) | ||
| } |
There was a problem hiding this comment.
Sorry😓, this was already mentioned in another comment.
Using a non-collection type as an argument value to the size(..) function results in a runtime error.
For developer experience, why not add a collection type constraint to the generic type parameter so that a compilation error can occur instead of a runtime error?
Motivation
Modifications
Commit Convention Rule
commit typeplease describe it on the Pull RequestResult
sizeis added.Closes