April 2012 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Updated: (HHH-1496) A new dialect is required for MySQL NDB clustered table types

by Strong Liu (JIRA)

[ https://hibernate.onjira.com/browse/HHH-1496?page=com.atlassian.jira.plug... ] Strong Liu updated HHH-1496: ---------------------------- Pull Requests: https://github.com/hibernate/hibernate-orm/pull/308 (was: https://github.com/hibernate/hibernate-orm/pull/308) Fix Version/s: 4.1.3 > A new dialect is required for MySQL NDB clustered table types > ------------------------------------------------------------- > > Key: HHH-1496 > URL: https://hibernate.onjira.com/browse/HHH-1496 > Project: Hibernate ORM > Issue Type: Improvement > Components: core > Affects Versions: 3.1.2 > Reporter: Darran Lofthouse > Assignee: Strong Liu > Fix For: 3.5.x, 4.1.3 > > Attachments: HHH-1496.diff > > > A new dialect is required for MySQL NDB clustered table types > http://dev.mysql.com/doc/refman/5.0/en/create-table.html > Either ENGINE=NDB or ENGINE=NDBCLUSTER > Also FYI ENGINE is the prefered way of specifying the type over TYPE so MySQLMyISAMDialect and MySQLInnoDBDialect could also be updated to use ENGINE -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 12 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-1496) A new dialect is required for MySQL NDB clustered table types

by Zbyněk Roubalík (JIRA)

[ https://hibernate.onjira.com/browse/HHH-1496?page=com.atlassian.jira.plug... ] Zbyněk Roubalík commented on HHH-1496: -------------------------------------- https://github.com/hibernate/hibernate-orm/pull/308 > A new dialect is required for MySQL NDB clustered table types > ------------------------------------------------------------- > > Key: HHH-1496 > URL: https://hibernate.onjira.com/browse/HHH-1496 > Project: Hibernate ORM > Issue Type: Improvement > Components: core > Affects Versions: 3.1.2 > Reporter: Darran Lofthouse > Assignee: Strong Liu > Fix For: 3.5.x > > Attachments: HHH-1496.diff > > > A new dialect is required for MySQL NDB clustered table types > http://dev.mysql.com/doc/refman/5.0/en/create-table.html > Either ENGINE=NDB or ENGINE=NDBCLUSTER > Also FYI ENGINE is the prefered way of specifying the type over TYPE so MySQLMyISAMDialect and MySQLInnoDBDialect could also be updated to use ENGINE -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 12 months

1
0
0 / 0

[Hibernate-JIRA] Updated: (HHH-1496) A new dialect is required for MySQL NDB clustered table types

by Strong Liu (JIRA)

[ https://hibernate.onjira.com/browse/HHH-1496?page=com.atlassian.jira.plug... ] Strong Liu updated HHH-1496: ---------------------------- Pull Requests: https://github.com/hibernate/hibernate-orm/pull/308 > A new dialect is required for MySQL NDB clustered table types > ------------------------------------------------------------- > > Key: HHH-1496 > URL: https://hibernate.onjira.com/browse/HHH-1496 > Project: Hibernate ORM > Issue Type: Improvement > Components: core > Affects Versions: 3.1.2 > Reporter: Darran Lofthouse > Assignee: Strong Liu > Fix For: 3.5.x > > Attachments: HHH-1496.diff > > > A new dialect is required for MySQL NDB clustered table types > http://dev.mysql.com/doc/refman/5.0/en/create-table.html > Either ENGINE=NDB or ENGINE=NDBCLUSTER > Also FYI ENGINE is the prefered way of specifying the type over TYPE so MySQLMyISAMDialect and MySQLInnoDBDialect could also be updated to use ENGINE -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 12 months

1
0
0 / 0

[Hibernate-JIRA] Assigned: (HHH-1496) A new dialect is required for MySQL NDB clustered table types

by Strong Liu (JIRA)

[ https://hibernate.onjira.com/browse/HHH-1496?page=com.atlassian.jira.plug... ] Strong Liu reassigned HHH-1496: ------------------------------- Assignee: Strong Liu (was: Juraci Paixão Kröhling) > A new dialect is required for MySQL NDB clustered table types > ------------------------------------------------------------- > > Key: HHH-1496 > URL: https://hibernate.onjira.com/browse/HHH-1496 > Project: Hibernate ORM > Issue Type: Improvement > Components: core > Affects Versions: 3.1.2 > Reporter: Darran Lofthouse > Assignee: Strong Liu > Fix For: 3.5.x > > Attachments: HHH-1496.diff > > > A new dialect is required for MySQL NDB clustered table types > http://dev.mysql.com/doc/refman/5.0/en/create-table.html > Either ENGINE=NDB or ENGINE=NDBCLUSTER > Also FYI ENGINE is the prefered way of specifying the type over TYPE so MySQLMyISAMDialect and MySQLInnoDBDialect could also be updated to use ENGINE -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 12 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-5858) Cannot load entities with Clob or Lob properties into stateless sessions

by James Roper (JIRA)

Cannot load entities with Clob or Lob properties into stateless sessions ------------------------------------------------------------------------ Key: HHH-5858 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5858 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.1 Reporter: James Roper I have a an entity with a Clob property: {code:java} @Lob private Clob clobProperty; {code} When I try and load it in a stateless session, I get: {noformat} Exception in thread "main" java.lang.ClassCastException: org.hibernate.impl.StatelessSessionImpl cannot be cast to org.hibernate.engine.jdbc.LobCreationContext at org.hibernate.Hibernate.getLobCreator(Hibernate.java:420) at org.hibernate.type.ClobType.nullSafeGet(ClobType.java:114) at org.hibernate.type.AbstractType.hydrate(AbstractType.java:105) at org.hibernate.persister.entity.AbstractEntityPersister.hydrate(AbstractEntityPersister.java:2267) at org.hibernate.loader.Loader.loadFromResultSet(Loader.java:1423) at org.hibernate.loader.Loader.instanceNotYetLoaded(Loader.java:1351) at org.hibernate.loader.Loader.getRow(Loader.java:1251) at org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:619) at org.hibernate.loader.Loader.loadSingleRow(Loader.java:307) at org.hibernate.impl.ScrollableResultsImpl.prepareCurrentRow(ScrollableResultsImpl.java:254) at org.hibernate.impl.ScrollableResultsImpl.next(ScrollableResultsImpl.java:123) {noformat} If Lobs in stateless sessions isn't supported, then at very least an error message to that effect should be thrown and the docs should be updated to reflect this, but I don't see why that should be the case, especially considering that both Lobs and stateless session both serve very similar purposes, they are for use when dealing with large datasets that may not fit in memory, and so could well be used together. -- 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, 12 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-7040) Define source of "id generators"

by Steve Ebersole (JIRA)

Define source of "id generators" -------------------------------- Key: HHH-7040 URL: https://hibernate.onjira.com/browse/HHH-7040 Project: Hibernate ORM Issue Type: Task Components: core, metamodel Reporter: Steve Ebersole Fix For: 5.0.0 This is annotation specific, but create the notion of source for "global" identifier generator definitions. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 12 months

3
8
0 / 0

[Hibernate-JIRA] Created: (HHH-4808) SessionImpl.initializeCollection() does not release JDBC connection (if outside of a transaction)

by Martin Renner (JIRA)

SessionImpl.initializeCollection() does not release JDBC connection (if outside of a transaction) ------------------------------------------------------------------------------------------------- Key: HHH-4808 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4808 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.2, 3.2.7 Reporter: Martin Renner Priority: Critical With {{ConnectionReleaseMode.AFTER_TRANSACTION}} (the default), Hibernate does not release the JDBC connection when resolving a lazily loaded collection, if this happens *outside* of an active transaction. First, I will describe, what happens if Hibernate executes a query outside of a transaction. Then I will describe how lazy collection loading behaves differently. When the method {{list}} of a query ({{QueryImpl.java}}) is getting called, Hibernate delegates to {{SessionImpl.list()}}. After having loaded the list, {{SessionImpl.list()}} calls {{SessionImpl.afterOperation()}}, which calls {{jdbcContext.afterNontransactionalQuery()}} (as there is no active transaction). This leads to {{ConnectionManager.afterTransaction()}} which releases the JDBC connection. This is exactly what I expect to happen. Now to the lazily loaded collection: {{Hibernate.initialize(collection)}} and {{person.getPets().size()}} both end up in {{SessionImpl.initializeCollection()}}. This call gets dispatched down to {{Loader.doQueryAndInitializeNonLazyCollections()}} and {{Loader.doQuery()}}. The important fact is, that {{ConnectionManager.afterTransaction()}} never gets called (like in the query-example above). The result is, that the JDBC connection is not released. IMHO resolving of a lazily loaded collection should behave like executing a query. {{SessionImpl.initializeCollection()}} should call {{SessionImpl.afterOperation()}} in the same way as {{SessionImpl.list()}} is doing this. I will attach a small demo application which shows the difference (concerning {{ConnectionManager}}) between queries and collections. -- 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, 12 months

2
5
0 / 0

[Hibernate-JIRA] Created: (HV-554) Regular Expression for @Email

by William Hardwick (JIRA)

Regular Expression for @Email ------------------------------ Key: HV-554 URL: https://hibernate.onjira.com/browse/HV-554 Project: Hibernate Validator Issue Type: Improvement Components: validators Affects Versions: 4.2.0.Final Reporter: William Hardwick Priority: Minor It would be nice if @Email allowed for a regular expression like @URL does. For example, we wanted to restrict emails to external addresses only (i.e. ending in .com, .net, etc.), but the @Email validation allows internal addresses as well, for example bob@mycompany instead of bob(a)mycompany.com. We had to write our own custom validation to handle this. @Email(regexp="myRegexp") -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 12 months

3
5
0 / 0

[Hibernate-JIRA] Created: (HHH-7240) Develop identifier handling in new metamodel

by Steve Ebersole (JIRA)

Develop identifier handling in new metamodel -------------------------------------------- Key: HHH-7240 URL: https://hibernate.onjira.com/browse/HHH-7240 Project: Hibernate ORM Issue Type: Task Components: core, metamodel Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 5.0.0 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 12 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-1092) Indexembedded still includes id of embedded entity even when not in includePaths

by Peter B. Vahlstrup (JIRA)

Indexembedded still includes id of embedded entity even when not in includePaths -------------------------------------------------------------------------------- Key: HSEARCH-1092 URL: https://hibernate.onjira.com/browse/HSEARCH-1092 Project: Hibernate Search Issue Type: Bug Components: mapping Affects Versions: 4.1.0.Final Environment: java 7, Lucene 3.5, HSearch 4.1, Hibernate 4.1 Reporter: Peter B. Vahlstrup When using indexembedded with includePaths the id of the embedded entity is still included even though it is not in the include path. Is this correct behavior. As I understand the documentation the includePaths (with depth=0 (default)) should only include the specified paths? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 12 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues April 2012