hibernate-orm
hibernate-orm copied to clipboard
hibernate
HHH-14076 Informix Boolean legacy support
A failed hibernate-envers test on my local build passed without errors. My build environment : JVM: 1.8.0_202 (Oracle Corporation 25.202-b08) OS: Windows 10 10.0 amd64
I'm against this change. We generally don't have Dialect-specific configuration properties, and we usually manage different database versions by Dialect inheritance (in H5) or by automatically detecting the database version (in H6).
Hibernate already has way too many configuration properties, and I don't think we should add a new one to solve this problem.
As I mentioned in the JIRA issue, InformixDialect should not mention support for Infromix v7.3 since Boolean type was not supported at that time. My solution was inspired by SAP HANA Driver and its variable hibernate.dialect.hana.use_legacy_boolean_type.
My solution was inspired by SAP HANA Driver and its variable
hibernate.dialect.hana.use_legacy_boolean_type.
Yeah, well I'm also a bit skeptical of those config properties and I would like to know why @Sanne introduced them.
If there really is a need to be able to globally select the use of SMALLINT instead of BOOLEAN via a property setting rather than looking at the version of the database (and I can certainly see why there might be) then there should be a single global setting for that; it shouldn't be Dialect-specific.
use_legacy_boolean_type
regarding HANA, sorry it wasn't me introducing them. I believe all HANA related things are maintained by SAP's expert @breglerj .
+1 to improve things in ORM 6 but I'm ok to keep things afload in 5 - there certainly are constraints when working in 5.
OK sorry @Sanne it was your name popped up in blame :-)
Sure, I'm not suggesting we remove them from 5 but it would be nice if we could remove them in H6. It just seems like if no other dialects require dialect-specific configuration, why would HANA need it? It's not as if it's one of our most-heavily-used platforms.
OK sorry @Sanne it was your name popped up in blame :-)
Hey I try to refactor code sometimes, git will blame me often :)
Sure, I'm not suggesting we remove them from 5 but it would be nice if we could remove them in H6. It just seems like if no other dialects require dialect-specific configuration, why would HANA need it? It's not as if it's one of our most-heavily-used platforms.
+1
FWIW, there's strong interest in the HANA support.
@gavinking: Sometimes it's not possible to determine the behavior from the dialect version alone. For example, in older versions HANA didn't have a native boolean type and used SMALLINT instead. If an application upgraded HANA to a version that now supported the BOOLEAN type and used the corresponding dialect there would now be a mismatch between what the dialect expects and the actual tables in the database. To not force all users to migrate the persistence after a database upgrade I introduced the parameter.
There are similar reasons for the other parameters. If you prefer making them global config parameters I'd be fine with that, but I don't think it would make sense to have a global treat_double_typed_fields_as_decimal parameter which only exists because of a HANA-specific behavior.
I'm not sure why I introduced a database-specific parameter, but I was using the other dialects as templates and may have seen the Oracle parameter hibernate.dialect.oracle.prefer_long_raw.
in older versions HANA didn't have a native boolean type and used SMALLINT instead. If an application upgraded HANA to a version that now supported the BOOLEAN type and used the corresponding dialect there would now be a mismatch between what the dialect expects and the actual tables in the database.
Right, so that was what I had intuited the motivation to be. The thing is that quite a few dialects introduced boolean types over the last few years, including DB2 and as we see here appparently Informix. So by making this Dialect-specific we wound up in a situation where we now need hibernate.dialect.informix.use_legacy_boolean_type and hibernate.dialect.db2.use_legacy_boolean_type, etc. Which is sort of a mess.
I'm not blaming you, since of course you were focused on the problem at hand. I'm just saying that it's something we should get sorted out for H6. (And of all people I am surely the most to blame for Hibernate having too many toggles and switches.)
If you prefer making them global config parameters I'd be fine with that
Well indeed hibernate.dialect.hana.use_unicode_string_types seems to be of the same sort as hibernate.dialect.hana.use_legacy_boolean_type. If it's needed, it should be global.
I don't think it would make sense to have a global
treat_double_typed_fields_as_decimalparameter which only exists because of a HANA-specific behavior.
I don't know what this is about because the URL in the code comment sends me to a page which wants me to log in. But it looks like some sort of JDBC driver bug. Is it fixed now?
Thanks for creating the Jira ticket.
I don't know what this is about because the URL in the code comment sends me to a page which wants me to log in. But it looks like some sort of JDBC driver bug. Is it fixed now?
Yes, it should be fixed now.
Like I said, I'm completely fine with making the parameters global. Let me know if you need me to do anything.
I don't know what this is about because the URL in the code comment sends me to a page which wants me to log in. But it looks like some sort of JDBC driver bug. Is it fixed now?
Yes, it should be fixed now.
In that case I would say we could remove that property in H6.
I don't know what this is about because the URL in the code comment sends me to a page which wants me to log in. But it looks like some sort of JDBC driver bug. Is it fixed now?
Yes, it should be fixed now.
In that case I would say we could remove that property in H6.
I agree.