-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
feat: allow DefaultSqlSessionFactory
to provide a custom SqlSession
#3128
feat: allow DefaultSqlSessionFactory
to provide a custom SqlSession
#3128
Conversation
Hi @harawata, do you have some feedback on this one? |
I'm not sure about extending If you revert the |
@harawata I'm fine with reverting the change to |
c49bfc5
to
dddd9f7
Compare
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.
Thank you for the update, @epochcoder !
Could you fix the two minor issues and force-push?
If you are busy, please let me know and I'll do it.
src/main/java/org/apache/ibatis/session/defaults/DefaultSqlSession.java
Outdated
Show resolved
Hide resolved
src/test/java/org/apache/ibatis/session/defaults/ExtendedSqlSessionFactoryTest.java
Outdated
Show resolved
Hide resolved
Please feel free to do it @harawata , if not, I'll do this by end of day GMT+2 tommorow 😊 |
Thank you, @epochcoder ! |
Hi Maintainers!
While extending
SqlSessionFactoryBuilder
allows users to fully customise their implementations ofSqlSessionFactory
andSqlSession
, the drawback is that you cannot use the safe defaults MyBatis provides anymore, which leaves two options:DefaultSqlSession
andDefaultSqlSessionFactory
, the drawbacks here are that you do not get upstream updates anymore and have to compare and update these files every release.I added a minimal test case which shows a structure that would allow the use of the defaults while providing important extension points.
Below is parked for future discussion:
Additionally, allow subclasses of
DefaultSqlSession
to callselectList(...)
, which allows providing a system wide result handler if user code did not specify one.I understand that this is definitely not a common use case, but believe the changes required are so minimal that it would provide a good tradeoff.
PS: note that the result handler is not the only reason here, we do quite some custom work (in our codebase) in the factory and session respectively.