Are you saying you are trying to prevent developers from using native SQL queries? If so there is no setting to turn it off. It seems to me this is more of an issue of communicating with your developers and maybe coming up with some Hibernate coding standards that they need to adhere to. Training might also be useful as often times when this is misused it is due to a lack of understanding of how Hibernate works.
That said I suppose if you were really ambitious you could create a find bugs,checkstyle or PMD rule to detect use of native queries and flag it as a violation. However I think the previous suggestion is more correct, as there are valid use cases for using native SQL in some cases.
The only way you can stop them 100% is by changing hibernate code and recompiling it I will strongly discourage you from doing this
You may not be able to stop them 100%, but you might be able to make it difficult for them. It will require some gymnastics, so again I don't reccomend it. It's better to train your developers than to cripple a library. However, if you have to do it, you could do this by basically proxying the Session. Let's say you have a your own implementation of Session that wraps the Session object that is implemented by Hibernate. For all calls, it can pass through to the underlying object, except for createSQLQuery which throws an exception
The question, how do you make it so it's easier for developers to use your proxy session instead of the real session created by hibernate. That depends on what your overall design is. Are you using some sort of DI framework? If yes then you can easily configure it to inject the session proxy. Do you have your own factory to get the session? If yes, then you just change the factory to return the proxy session. Do all the DAO classes create their own session? then your job is difficult, because you have to change all the lines of code
Again, not reccomended, because a developer can easily circumvent whatever mechanism you have built. And there might be cases where you do legitimately want to use native queries. As Bill said, it's better to train the developers than to cripple the tools that they have.
Anant K Agarwal
Joined: Mar 01, 2012
Thank you Bill for your response. You will always find some nasty developer who is not following this rule despite of training and communication.
Was thinking if we can avoid this by using some means. I hope you understand.