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
allow null input and no need to use and() at WhereDsl #75
Conversation
core/src/main/kotlin/com/linecorp/kotlinjdsl/querydsl/QueryDslImpl.kt
Outdated
Show resolved
Hide resolved
@@ -67,8 +67,7 @@ internal class QueryDslImplWhereTest : WithKotlinJdslAssertions { | |||
val actual = QueryDslImpl(Data1::class.java).apply { | |||
select(distinct = true, Data1::class.java) | |||
from(entity(Data1::class)) | |||
where(predicateSpec1) | |||
where(predicateSpec2) | |||
where(predicateSpec1,predicateSpec2) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-- korean
where 메소드는 predicates를 받을 수 없기 때문에 잘못된 테스트로 보입니다.
-- english
The test appears to be an invalid test because where method cannot receive predicates as parameter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-- korean
where 메소드에 대한 검증은 총 6개로 이루어져야 할 것으로 보입니다.
where
, where - null
, whereAnd - vararg
, whereAnd - list
, whereOr - vararg
, whereOr - list
-- english
It seems that there should be a total of six tests for the where method.
where
, where - null
, whereAnd - vararg
, whereAnd - list
, whereOr - vararg
, whereOr - list
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code formatting seems to be necessary as well.
where(predicateSpec1, predicateSpec2)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@shouwn 말씀하신 테스트 케이스들 추가하였습니다.
feature: add whereAnd and whereOr method
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cj848 refactor: rollback wheres() testCase에 해당 내용 적용하였습니다. 현재는 다른 메소드로 변경되었습니다.
@Test | ||
fun nullInFirstWheres() { | ||
fun allTypeWheres() { | ||
// given | ||
val predicateSpec1: PredicateSpec? = null | ||
val nullPredicateSpec: PredicateSpec? = null | ||
val predicateSpec1: PredicateSpec = mockk() | ||
val predicateSpec2: PredicateSpec = mockk() | ||
val predicateSpec3: PredicateSpec = mockk() | ||
|
||
// when | ||
val actual = QueryDslImpl(Data1::class.java).apply { | ||
select(distinct = true, Data1::class.java) | ||
from(entity(Data1::class)) | ||
where(predicateSpec1,predicateSpec2,predicateSpec3) | ||
where(nullPredicateSpec) | ||
where(predicateSpec1) | ||
whereAnd(nullPredicateSpec, predicateSpec1, predicateSpec2) | ||
whereOr(nullPredicateSpec, predicateSpec1, predicateSpec2) | ||
} | ||
|
||
// then | ||
val criteriaQuerySpec = actual.createCriteriaQuerySpec() | ||
|
||
assertThat(criteriaQuerySpec.where).isEqualTo( | ||
WhereClause(AndSpec(listOf(predicateSpec2, predicateSpec3))) | ||
WhereClause( | ||
AndSpec( | ||
listOf( | ||
predicateSpec1, | ||
AndSpec(listOf(predicateSpec1, predicateSpec2)), | ||
OrSpec(listOf(predicateSpec1, predicateSpec2)) | ||
) | ||
) | ||
) | ||
) | ||
|
||
val subquerySpec = actual.createSubquerySpec() | ||
|
||
assertThat(subquerySpec.where).isEqualTo( | ||
WhereClause(AndSpec(listOf(predicateSpec2, predicateSpec3))) | ||
WhereClause( | ||
AndSpec( | ||
listOf( | ||
predicateSpec1, | ||
AndSpec(listOf(predicateSpec1, predicateSpec2)), | ||
OrSpec(listOf(predicateSpec1, predicateSpec2)) | ||
) | ||
) | ||
) | ||
) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
각 메소드 별 단위 테스트는 있는데, 여러 조건들이 다 붙은 경우의 케이스도 검증이 필요하다고 생각하여 넣어보았습니다.
fun whereAnd(vararg predicates: PredicateSpec?) = whereAnd(predicates.toList()) | ||
fun whereAnd(predicates: List<PredicateSpec?>) | ||
|
||
fun whereOr(vararg predicates: PredicateSpec?) = whereOr(predicates.toList()) | ||
fun whereOr(predicates: List<PredicateSpec?>) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@shouwn whereAnd에 vararg를 인자로 넣어도, 내부에서 리스트로 변환되어 리스트를 인자로 넣은 경우와 같은데, 테스트 케이스를 따로 가져가야 할 이유가 있을까요? 내부에선 같더라도 어쨌든 다른 인터페이스이기때문에 그런 걸까요??
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-- korean
@jaeykweon 넵 말씀해주신 다른 인터페이스이기 때문입니다.
내부 구현이 동일하다는 것은 개발자만이 알고 있는 사실입니다. 개인적으로는 테스트는 내부 구현을 알고 작성한다기 보다 외부의 시점에서 작성하는 것이 맞다고 생각하기 때문에 vararg와 list 테스트를 별도로 가져가도록 말씀드렸습니다.
-- english
Yes, it's because different interface.
Only developers know that internal implementations are same. Personally, The vararg and list test should be separated because I think it is right to write the test from an external perspective rather than knowing the internal implementation.
@shouwn reactive쪽도 영향이 있어서 추가하였습니다 |
cc. @huisam @cj848 @pickmoment |
@shouwn commit lint 오류난 부분은 수정하여 push -f 하면 될까요?? |
core/src/main/kotlin/com/linecorp/kotlinjdsl/querydsl/QueryDslImpl.kt
Outdated
Show resolved
Hide resolved
reactive-core/src/main/kotlin/com/linecorp/kotlinjdsl/querydsl/ReactiveQueryDslImpl.kt
Outdated
Show resolved
Hide resolved
please check lint and force push too. -- korean |
2ade308
to
7bdb0de
Compare
@cj848 변경하였습니다! |
It would be nice if the readme.md explanation could also be added. -- korean |
@cj848 readMe 설명 추가하였습니다. |
CLA 사인 부탁드립니다. please sign a CLA |
@cj848 서명하였습니다! |
#### with nullable condition | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-- korean
안녕하세요. :)
해당 documentation 을 조금 더 자세하게 작성해주시면 좋겠습니다. 왜냐하면 where PredicateSpec 에 대하여 null 을 허용되는 스펙으로 되었기 때문인데요.
where 의 PredicateSpec 을 nullable 로 바꾸게 되면 말씀주신 것처럼 nullable 한 검색조건에 대하여
코드를 조금 더 가독성 있게 작성할 수 있다는 장점을 얻었지만,
반대로 얻었던 단점은 where 조건에 대하여 개발자가 empty spec이 들어갈 수 있다라는 컴파일 타임에 인지할 수 있는 상황이 사라졌다고 생각합니다.
이는 충분한 테스트와 코드 리뷰를 통해서 발견할 수도 있지만, 라이브러리를 제공하는 사람의 입장에서도 어느정도 주의점으로 명시할 정도라고 생각되기도 하는데요.
설명
과 주의점
에 대하여 작성해주셔도 괜찮을 것 같은 의견인데, 어떠신가요?
-- english
Hello. :)
I would appreciate it if you could write the documentation in more detail. Because null is allowed spec for where Predict Spec.
If you change the predicate spec to nullable, you can write the code more legibly for null search conditions, as you mentioned
Conversely, I think that the situation that developers can recognize about where conditions can be filled with empty spec has disappeared.
This can be found through sufficient testing and code review, but I think it's a caution point for the library provider.
I think it would be okay if you write down 'Explanation' and 'Caution', what do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@huisam 좋은 리뷰 감사합니다!
with nullable condition
null
in where condition
converts to EmptyPredicateSpec
object.
note that EmptyPredicateSpec
turns into 1=1
sql
val books: List<Book> = queryFactory.listQuery {
select(entity(Book::class))
from(entity(Book::class))
where(
name?.run { column(Book::author).equal(this) }
)
}
이렇게 작성해보았는데 괜찮을까요?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-- korean
네 저는 충분하다고 생각합니다.
-- english
Yes, I think that's enough.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@huisam
docs: add descriptions for where method
말씀하신 null condition에 대한 설명을 적은 커밋입니다.
또한 whereAnd와 whereOr에 대한 설명도 필요하다고 생각해서 적어보았는데 괜찮은지 피드백 부탁드리겠습니다 감사합니다!
Motivation:
#74
Modifications:
Commit Convention Rule
Result:
we can
Closes #. (If this resolves the issue.)