3:45 p.m.
Unequivocally map MySQL LOB types to the LONG variant
-----------------------------------------------------
Key: HHH-2669
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2669
Project: Hibernate3
Issue Type: Improvement
Components: core
Reporter: Steve Ebersole
Assignee: Steve Ebersole
Fix For: 3.3
MySQL differentiates different "sizes" of LOBs. Apparently, the smaller types
offer no storage benefit nor performance gain. So we should consider mapping the LOB
types in the MySQL dialect to the LON variants in all cases.
The current setup causes truncation headaches for users, apparently unnecessarily.
--
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
4:07 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2669) Unequivocally map MySQL LOB types to the LONG variant
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2669?page=c...
]
Mark Matthews commented on HHH-2669:
------------------------------------
Just a quick comment validating Steve's approach, since we discussed this in IRC on
freenode and I asked around internally (and went through the source of the server), and
this is indeed the case. The different BLOB/TEXT types seem to be designed to prevent
storage over-allocation, since MySQL doesn't have CHECK CONSTRAINT.
Unequivocally map MySQL LOB types to the LONG variant
-----------------------------------------------------
Key: HHH-2669
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2669
Project: Hibernate3
Issue Type: Improvement
Components: core
Reporter: Steve Ebersole
Assignee: Steve Ebersole
Fix For: 3.3
MySQL differentiates different "sizes" of LOBs. Apparently, the smaller types
offer no storage benefit nor performance gain. So we should consider mapping the LOB
types in the MySQL dialect to the LON variants in all cases.
The current setup causes truncation headaches for users, apparently unnecessarily.
--
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
4:14 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2669) Unequivocally map MySQL LOB types to the LONG variant
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2669?page=c...
]
Steve Ebersole commented on HHH-2669:
-------------------------------------
Right, specifically the discussion revolved around the default environment should be
something that "just works". For those that need to be cognizant of this, it is
easy enough to supply a custom dialect reverting to the current behavior.
Unequivocally map MySQL LOB types to the LONG variant
-----------------------------------------------------
Key: HHH-2669
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2669
Project: Hibernate3
Issue Type: Improvement
Components: core
Reporter: Steve Ebersole
Assignee: Steve Ebersole
Fix For: 3.3
MySQL differentiates different "sizes" of LOBs. Apparently, the smaller types
offer no storage benefit nor performance gain. So we should consider mapping the LOB
types in the MySQL dialect to the LON variants in all cases.
The current setup causes truncation headaches for users, apparently unnecessarily.
--
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
12:27 a.m.
New subject: [Hibernate-JIRA] Closed: (HHH-2669) Unequivocally map MySQL LOB types to the LONG variant
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2669?page=c...
]
Steve Ebersole closed HHH-2669.
-------------------------------
Resolution: Fixed
applied to trunk
Unequivocally map MySQL LOB types to the LONG variant
-----------------------------------------------------
Key: HHH-2669
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2669
Project: Hibernate3
Issue Type: Improvement
Components: core
Reporter: Steve Ebersole
Assignee: Steve Ebersole
Fix For: 3.3
MySQL differentiates different "sizes" of LOBs. Apparently, the smaller types
offer no storage benefit nor performance gain. So we should consider mapping the LOB
types in the MySQL dialect to the LON variants in all cases.
The current setup causes truncation headaches for users, apparently unnecessarily.
--
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
8:19 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2669) Unequivocally map MySQL LOB types to the LONG variant
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2669?page=c...
]
Max Bowsher commented on HHH-2669:
----------------------------------
I just upgraded from 3.2.x to 3.3.x (yes, a bit late, I know) and found my generated
schema changing types under me. OK, that I more-or-less expected.
But I did expect that I ought to be able to override Hibernate's default decisions
using <property length="NNNN"/>.
I've got no problem with changing the default to be the long* variants, but surely an
explicit length request should still select the most appropriate MySQL type?
Unequivocally map MySQL LOB types to the LONG variant
-----------------------------------------------------
Key: HHH-2669
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2669
Project: Hibernate Core
Issue Type: Improvement
Components: core
Reporter: Steve Ebersole
Assignee: Steve Ebersole
Fix For: 3.3.0.CR1
MySQL differentiates different "sizes" of LOBs. Apparently, the smaller types
offer no storage benefit nor performance gain. So we should consider mapping the LOB
types in the MySQL dialect to the LON variants in all cases.
The current setup causes truncation headaches for users, apparently unnecessarily.
--
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
2:46 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2669) Unequivocally map MySQL LOB types to the LONG variant
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2669?page=c...
]
Gail Badner commented on HHH-2669:
----------------------------------
Mark, I noticed that the fix to MySQLDialect.java commented out:
// registerColumnType( Types.VARCHAR, 16777215, "mediumtext" );
// registerColumnType( Types.VARCHAR, 65535, "text" );
but did not comment out the following:
registerColumnType( Types.VARBINARY, 16777215, "mediumblob" );
registerColumnType( Types.VARBINARY, 65535, "blob" );
Should these also be commented out?
Unequivocally map MySQL LOB types to the LONG variant
-----------------------------------------------------
Key: HHH-2669
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2669
Project: Hibernate Core
Issue Type: Improvement
Components: core
Reporter: Steve Ebersole
Assignee: Steve Ebersole
Fix For: 3.3.0.CR1
MySQL differentiates different "sizes" of LOBs. Apparently, the smaller types
offer no storage benefit nor performance gain. So we should consider mapping the LOB
types in the MySQL dialect to the LON variants in all cases.
The current setup causes truncation headaches for users, apparently unnecessarily.
--
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
5716
days inactive
6406
days old
hibernate-issues@lists.jboss.org
5 comments
4 participants
participants (4)
-
Gail Badner (JIRA) -
Mark Matthews (JIRA)
-
Max Bowsher (JIRA)
-
Steve Ebersole (JIRA)