Closed epochcoder closed 4 months ago
Hi @harawata, do you have some feedback on this one?
DefaultSqlSessionFactory
looks OK.
I'm not sure about extending DefaultSqlSession
, though.
This particular change looks harmless and may be sufficient for your needs, but it could trigger future trickier requests.
If you revert the DefaultSqlSession
, I will merge the DefaultSqlSessionFactory
change.
If you cannot give up the DefaultSqlSession
change, I would like other devs' opinion.
@harawata I'm fine with reverting the change to DefaultSqlSession
for now, we can discuss it at a later point. Ill update the PR with the changes
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.