-
Notifications
You must be signed in to change notification settings - Fork 926
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
Unwanted implied commits may occur for Oracle and MySql #3474
Comments
After debugging more I found out that this only happens with the |
The use of this executor may happen when inheritance is mapped, on types mapped as abstract or having subclasses mapped. Such cases may cause the data of the entity to be split in many tables. Nonetheless, you may define a custom Oracle dialect deriving from the one you are currently using, to check if overriding the |
So everyone using oracle needs a custom dialect when there is a build-in oracle dialect that doesn't reflect the behavior of a oracle database when it comes to |
No. That may be a needed workaround for now, if that does solve anything. I was actually asking you to check this. So you have checked and confirm it solves your case, thanks.
No idea, apart default dialect behavior. Things are that way since very long. According to your writings, that would be a bug, especially if this Oracle commit behavior you explain on temp table DDL affects all of its versions, whatever the way they are configured. But looking on Hibernate side, their OracleDialect does not override it either to handle it in isolation. (On their side, that is now So, I find it strange that the trouble would have stayed for so long both on our side and on their side. Are you sure that is not a trouble specific to your Oracle server configuration or something else specific to your setup? The best way to ascertain this would be to provide a test case triggering the failure (I mean, unwanted commit, see contributing), so we can check that does occur too with our CI. |
Sorry for the misunderstanding. PS: When looking at the comments of |
@Epicycle23, at this stage we're just asking if to test on your setup if using a custom dialect with the setting enabled would solve your problem. |
Yes it does solve the problem. |
Thanks for confirming. |
On NHibernate side, that is not the case. Hibernate code has been ported to .Net sometimes without properly cleaning comments irrelevant for .Net. (On Hibernate side there is some code determining this property from the database metadata, excepted the end result seems used nowhere...)
|
Fixed by #3485. |
NHibernate Version: 5.4.2
.net framework 4.8
We observed that running ExecuteUpdate on a HQL-Query causes updates that have been done before to be committed afterwards.
Debugging into NHibernate I was able to track this down to
ShouldIsolateTemporaryTableDDL
at least it seems like it.For some reason NHibernate tries to create a (temporary) table which apparently fails because it already exists but just logs the error as debug and continues.
Since creating tables in oracle is causing a commit this seems to be the issue.
I noticed that there is a function
ShouldIsolateTemporaryTableDDL
in the classAbstractStatementExecutor
which apparently first checks the dialect forPerformTemporaryTableDDLInIsolation
which returns false or rather null when using the oracle dialect which if I am understanding this correctly should return true because oracle has an implicit commit when doing DDL operations and therefore DDL should run in isolation.The text was updated successfully, but these errors were encountered: