[Hibernate-JIRA] Assigned: (HHH-468) MysqlDialect incorrectly maps java.lang.Boolean to SQL BIT
by Steve Ebersole (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-468?page=co... ]
Steve Ebersole reassigned HHH-468:
----------------------------------
Assignee: Steve Ebersole (was: Scott Marlow)
> MysqlDialect incorrectly maps java.lang.Boolean to SQL BIT
> ----------------------------------------------------------
>
> Key: HHH-468
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-468
> Project: Hibernate Core
> Issue Type: Bug
> Affects Versions: 3.0.3
> Environment: Hibernate 3.0, MySQL.
> Reporter: Mark Matthews
> Assignee: Steve Ebersole
> Fix For: 4.0.0.Alpha2
>
>
> I didn't track down how java.lang.Boolean gets mapped to Types.BIT in hibernate, but you probably _don't_ want to map to "bit" like you do in MysqlDialect.
> "bit", according to SQL99 (it's not in the core standard, and the type was actually dropped for sql2k3) is a bitfield, not a boolean value. You can of course define a bit(1), but it is technically more correct for java.lang.Boolean to map to a SQL BOOLEAN for MySQL since we support a BOOLEAN and a BIT.
> It looks like the JDBC-3.0 guys ignored what the standard said, because in reality you'd want BIT to map to something like byte[], or java.util.BitSet if you were tracking how the SQL standard defines BIT.
> I'm guessing you probably want to map to "boolean", which the JDBC driver will automagically convert for you, as it silently maps to TINYINT(1) on the server side.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[Hibernate-JIRA] Created: (HHH-6072) Logical delete support
by Joonas Koivunen (JIRA)
Logical delete support
----------------------
Key: HHH-6072
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6072
Project: Hibernate Core
Issue Type: New Feature
Components: core
Reporter: Joonas Koivunen
Logical delete is a common pattern which hibernate could support.
While discussing this at #hibernate with sebersole some an idea of @LogicalDelete popped up.
There was also discussion about conditional logical delete, as some applications might have business reasons to sometimes execute a logical delete, sometimes a physical delete. However as there is no simple answer to the question "what should the strategy look like" this should be scoped as a later feature issue, should @LogicalDelete get implemented.
In addition to replace @SQLDelete annotation use for logical delete, feature would also need to address:
* SELECTs (whether to select or filter the logically deleted)
* the used column and type for update statement
* handling Session#delete(Object) where entity is already logically deleted
* what happens to entity owned collections
* could/should the logical delete be cascadable?
* could undelete be handled in a way other than native sql update?
SELECTs could be either done with a pre-existing solution, which must be in use already where hibernate is used to logically delete entities and not to query them as normal entities. sebersole pointed out that full support for @LogicalDelete could implement this in a more integrated way.
The used column and type must be configurable, simple boolean was suggested; inhouse we use a timestamp.
Attempting to delete an already deleted entity should be treated as an error.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[Hibernate-JIRA] Closed: (HHH-26) Default UserType for java classes
by Steve Ebersole (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-26?page=com... ]
Steve Ebersole closed HHH-26.
-----------------------------
Assignee: (was: Michael Gloegl)
Resolution: Duplicate
This issue has been addressed by HHH-5138 since 3.6 You can define Types to use throughout a SessionFactory for a given java type.
> Default UserType for java classes
> ---------------------------------
>
> Key: HHH-26
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-26
> Project: Hibernate Core
> Issue Type: New Feature
> Components: core
> Affects Versions: 3.0 beta 1
> Reporter: Matthew Inger
> Priority: Minor
>
> It would be nice if the user could automatically assign a particular default UserType when certain java classes are encountered. For example, many shops have special handling for empty strings, since oracle does not allow empty strings, and instead inserts null values.
> We, in particular, put a single character string will a null byte (char(0)) into the db field, and when it is read, replace that with the empty string.
> In order to do this, we use a UserType, which has to be specified on every nullable string field. What we'd rather do is something like this in hibernate.cfg.xml:
> <default-type property-type="java.lang.String"
> class="com.synygy.core.hibernate.NullableStringType" />
> Is this possible to be put into the 3.0 release?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[Hibernate-JIRA] Updated: (HHH-468) MysqlDialect incorrectly maps java.lang.Boolean to SQL BIT
by Steve Ebersole (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-468?page=co... ]
Steve Ebersole updated HHH-468:
-------------------------------
Fix Version/s: 4.0.0.Alpha2
Actually, I think this can be handled by the notion we just added in 4.0 where a Dialect can redefine how to treat SQL types. The basic idea is that {{BooleanType}} would be changed to say that its sql-type is Types.BOOLEAN and that dialects which do not understand that would define an override to say to use Types.BIT instead. This is all based on the splitting of Type that we did internally into {{org.hibernate.type.descriptor.sql.SqlTypeDescriptor}} and {{org.hibernate.type.descriptor.java.JavaTypeDescriptor}}. Then org.hibernate.dialect.Dialect#resolveSqlTypeDescriptor is the piece at play here.
> MysqlDialect incorrectly maps java.lang.Boolean to SQL BIT
> ----------------------------------------------------------
>
> Key: HHH-468
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-468
> Project: Hibernate Core
> Issue Type: Bug
> Affects Versions: 3.0.3
> Environment: Hibernate 3.0, MySQL.
> Reporter: Mark Matthews
> Assignee: Scott Marlow
> Fix For: 4.0.0.Alpha2
>
>
> I didn't track down how java.lang.Boolean gets mapped to Types.BIT in hibernate, but you probably _don't_ want to map to "bit" like you do in MysqlDialect.
> "bit", according to SQL99 (it's not in the core standard, and the type was actually dropped for sql2k3) is a bitfield, not a boolean value. You can of course define a bit(1), but it is technically more correct for java.lang.Boolean to map to a SQL BOOLEAN for MySQL since we support a BOOLEAN and a BIT.
> It looks like the JDBC-3.0 guys ignored what the standard said, because in reality you'd want BIT to map to something like byte[], or java.util.BitSet if you were tracking how the SQL standard defines BIT.
> I'm guessing you probably want to map to "boolean", which the JDBC driver will automagically convert for you, as it silently maps to TINYINT(1) on the server side.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[Hibernate-JIRA] Created: (HHH-2640) Clob management and deadlock
by Samuel Emangard (JIRA)
Clob management and deadlock
----------------------------
Key: HHH-2640
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2640
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.0.ga
Environment: JDK 1.5, Oracle 10g v2
Reporter: Samuel Emangard
Priority: Trivial
Attachments: Samuel.rar
Mapping documents:
<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
'-//Hibernate/Hibernate Mapping DTD 3.0//EN'
'http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd'>
<hibernate-mapping package="com.toluna.samuel.hibernate.emailtemplate">
<class name="EmailTemplate" table="EmailTemplate">
<id name="id" type="long">
<column name="template_id" not-null="true"/>
<generator class="native"/>
</id>
<property name="name">
<column name="email_name" not-null="false"/>
</property>
<property name="htmlTextClob" type="clob">
<column name="html_Text" not-null="false"/>
</property>
<property name="plainTextClob" type="clob">
<column name="plain_Text" not-null="false"/>
</property>
</class>
</hibernate-mapping>
Extract also of my Java bean:
ublic class EmailTemplate {
private long id;
private String name;
private String plainText = " ";
private String htmlText = " ";
private Clob plainTextClob;
private Clob htmlTextClob;
...
Code of the test case:
Session ss = HibernateUtil.getSessionFactory().getCurrentSession();
//S_LOGGER.debug("Number of current Hibernate sessions: "+ HibernateUtil.getSessionFactory().getStatistics().getSessionOpenCount());
ss.getTransaction().begin();
EmailTemplate et = (EmailTemplate) ss.load(EmailTemplate.class, new Long("299941536982302"));
S_LOGGER.debug(et.getName());
Thread.sleep(5000);
S_LOGGER.debug("BEFORE FLUSH");
ss.flush();
S_LOGGER.debug("AFTER FLUSH");
ss.getTransaction().commit();
The generated SQL :
The load statement is always generated:
/* load com.toluna.samuel.hibernate.emailtemplate.EmailTemplate */ select
emailtempl0_.template_id as template1_0_0_,
emailtempl0_.email_name as email2_0_0_,
emailtempl0_.html_Text as html3_0_0_,
emailtempl0_.plain_Text as plain4_0_0_
from
EmailTemplate emailtempl0_
where
emailtempl0_.template_id=?
....
Depending on the implementation of the getter, the following update statement is generated:
/* update
com.toluna.samuel.hibernate.emailtemplate.EmailTemplate */ update
EmailTemplate
set
email_name=?,
html_Text=?,
plain_Text=?
where
template_id=?
Here is the getter:
Clob getHtmlTextClob() {
//1-
//return Hibernate.createClob(htmlText != null ? htmlText : " ");
//2-
return htmlTextClob;
}
With 1- the update statement is generated
With 2- the update statement is not generated
Why?
Extract of the setter:
void setHtmlTextClob(Clob htmlTextClob) {
this.htmlTextClob = htmlTextClob;
try {
if (htmlTextClob != null) {
htmlText = HibernateUtil.getStringFromClob(htmlTextClob);
//htmlText = "samuel";
} else
htmlText = "";
} catch (SQLException e) {
throw new RuntimeException(e);
} catch (IOException e) {
throw new RuntimeException(e);
}
}
I have also another more critical issue which seems tied to the previous:
If I write the following piece of test code instead of the one shown above:
Session ss = HibernateUtil.getSessionFactory().openSession();
//S_LOGGER.debug("Number of current Hibernate sessions: "+ HibernateUtil.getSessionFactory().getStatistics().getSessionOpenCount());
EmailTemplate et = (EmailTemplate) ss.load(EmailTemplate.class, new Long("299941536982302"));
S_LOGGER.debug(et.getName());
Thread.sleep(5000);
S_LOGGER.debug("BEFORE FLUSH");
ss.flush();
S_LOGGER.debug("AFTER FLUSH");
As you can see in this piece of code i do not manage transactions explicitly and in that case my 2 java threads generated update statements which never ended: there was a deadlock on the DB.
During the last test, If I still did not manage transactions explicitly but I modified the getter like that:
Clob getHtmlTextClob() {
return htmlTextClob;
}
Then neither update statements nor deadlock were generated.
I wrote this piece of test code to reproduce deadlock I was facing on my Jonas server.
Could you please help me to understand this behaviour?
Here is anextract of my hibernate.cfg.xml:
<property name="connection.url">jdbc:oracle:thin:@192.168.2.7:1521:tlorcl1</property>
<property name="connection.username">samuel</property>
<property name="connection.password">toluna</property>
<property name="connection.driver_class">oracle.jdbc.driver.OracleDriver</property>
<property name="dialect">org.hibernate.dialect.Oracle9Dialect</property>
<property name="hibernate.show_sql">true</property>
<property name="hibernate.format_sql">true</property>
<property name="hibernate.use_sql_comments">true</property>
<property name="myeclipse.connection.profile">QA</property>
<property name="current_session_context_class">thread</property>
Thanks in advance
Regards
Samuel
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month