-
Notifications
You must be signed in to change notification settings - Fork 88
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
fix: silently ignores exception when parameter setting to count query #781
Conversation
...pa/src/main/kotlin/com/linecorp/kotlinjdsl/support/spring/data/jpa/JpqlEntityManagerUtils.kt
Outdated
Show resolved
Hide resolved
ecb7a8b
to
fe2b4b4
Compare
.../main/kotlin/com/linecorp/kotlinjdsl/support/spring/data/jpa/javax/JpqlEntityManagerUtils.kt
Outdated
Show resolved
Hide resolved
.../main/kotlin/com/linecorp/kotlinjdsl/support/spring/data/jpa/javax/JpqlEntityManagerUtils.kt
Show resolved
Hide resolved
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #781 +/- ##
==========================================
- Coverage 91.73% 90.79% -0.94%
==========================================
Files 337 337
Lines 3447 3489 +42
Branches 209 221 +12
==========================================
+ Hits 3162 3168 +6
- Misses 223 253 +30
- Partials 62 68 +6 ☔ View full report in Codecov by Sentry. |
} | ||
} | ||
} | ||
|
||
private val log = LoggerFactory.getLogger(JpqlStageStatelessSessionUtils::class.java) |
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.
logger 가 클래스 안에서만 쓰이는걸로 보이는데 파일 스코프로 선언하신 이유가 있을까요?
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.
render/jpql/src/main/kotlin/com/linecorp/kotlinjdsl/render/jpql/JpqlRenderer.kt에서 logger를 선언하고 사용하는 부분을 참고해 같은 방식으로 하였습니다.
logger를 클래스 안으로 선언하는 것이 좋다고 생각하신다면 반영하겠습니다.
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.
이유가 궁금했던 것인데요, 기존에 있던 사례라면 따라도 상관은 없을 것 같습니다 :)
query.setParameter(name, value) | ||
} else if (log.isDebugEnabled) { | ||
log.debug( | ||
"No parameter named '{}' in query with named parameters [{}], parameter binding skipped", |
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.
{} 로 로그를 파라메터 파싱하는것보다는 $name 과 같이 처리하는게 어떨까요?
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.
성능상 문제 있을까 하여 따로 파라미터로 전달한 것이었는데, log.isDebugEnabled
로 출력할 수 있는지 확인하고 있고 가독성 측면에서도 좋을 것 같아 로그 출력 방식을 string template으로 바꿨습니다!
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.
{} 로 가져가는게 오히려 성능에 더 문제가 있을 수 있습니다 (일단 스트링 파싱을 해야하고 replace 후 재생성을 해야하니 문자열 연결보다 더 성능이 좋을 수는 없을것 같습니다 :)
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.
{} 로 가져가는게 오히려 성능에 더 문제가 있을 수 있습니다 (일단 스트링 파싱을 해야하고 replace 후 재생성을 해야하니 문자열 연결보다 더 성능이 좋을 수는 없을것 같습니다 :)
그렇겠네요. 하나 배웠습니다!
.../src/main/kotlin/com/linecorp/kotlinjdsl/support/eclipselink/javax/JpqlEntityManagerUtils.kt
Outdated
Show resolved
Hide resolved
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.
도움을 주셔서 정말 감사합니다!
query.setParameter(name, value) | ||
if (parameterNameSet.contains(name)) { | ||
query.setParameter(name, value) | ||
} else if (log.isDebugEnabled) { |
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.
이건 개인적인 취향이기 때문에 반영해주셔도 되고 안 해주셔도 됩니다.
개인적으로는 if else의 레벨을 맞추는 것을 선호합니다.
parameterNameSet
에 name
이 포함되어 있는지 여부와 log가 debug
레벨인지 여부는 같은 레벨의 비지니스로 보기 어렵다고 생각합니다.
그래서 개인적으로는 else 블록 안에서 if를 추가하는 것을 선호합니다.
그러면 코드를 해석할 때, 파라미터 이름이 없으면 다른 작업을 하게 되는데 그 중에서 로그 레벨이 debug면 로그를 출력한다
와 같이 읽을 수 있기 때문입니다.
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.
이거는 저도 조금 이상해 보이긴 했습니다 저는 수정하는게 좋을것 같습니다
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.
else 안에 if 들어가는 코드여서 바깥으로 뺐는데, 말씀해주신 대로 코드를 바꾸는 게 맞는 것 같습니다.
수정해서 커밋하겠습니다!
@bagger3025 오래 기다리셨습니다. 오늘 배포진행하겠습니다. |
Motivation
Modifications
Commit Convention Rule
commit type
please describe it on the Pull RequestResult
Closes