[Hibernate-JIRA] Created: (HHH-6604) confusing error message when OneToOne has a duplicate on one end
by Laura Dean (JIRA)
confusing error message when OneToOne has a duplicate on one end
----------------------------------------------------------------
Key: HHH-6604
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6604
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.6.6, 4.x
Environment: originally found with hibernate 3.6.6 and MS SQL Server; also happens when run in a hibernate unit test.
Reporter: Laura Dean
Priority: Minor
Attachments: OneToOne-error-message.patch
Suppose I have a Trousers entity with id 1, that knows about its TrousersZip, which has id 2. That is, my Trousers has zip_id = 2. (This part of the example comes from Hibernate's unit tests.)
Suppose the Trousers has a TrousersHanger, also one-to-one, but mapped on the TrousersHanger side. That is, the hanger points to its Trousers.
Now suppose I put two TrousersHangers into the database, both pointing at the same Trousers. (Naughty, I know; in the real world, it happened because of HHH-6484.)
When I then try to load the Trousers from the database, I get a very confusing error message:
org.hibernate.HibernateException: More than one row with the given identifier was found: 2, for class: org.hibernate.test.annotations.onetoone.Trousers
The message confuses me for three reasons:
1. I have only one row in the Trousers table.
2. That one row has ID 1.
3. My actual problem is with duplicate TrousersHangers, and neither one of them has ID 2.
In other words, where the heck did ID 2 come from?
As it turns out, hibernate finds the Trousers by id, then finds the Trousers by zip_id (to populate the TrousersZip object). It doesn't care about the duplicate results in the first query, but it does care the second time. But the error message doesn't mention that its ID is actually the zip_id, and a person could waste quite a bit of time before figuring out that the TrousersZip had anything to do with it. (Well, maybe not in this contrived example with only 3 entities. But in the real world, yeah.)
I've attached a junit test, adding to hibernate's own OneToOneTest.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[Hibernate-JIRA] Created: (HHH-5184) Create a ConnectionAcquisitionMode as corollary to ConnectionReleaseMode
by Steve Ebersole (JIRA)
Create a ConnectionAcquisitionMode as corollary to ConnectionReleaseMode
------------------------------------------------------------------------
Key: HHH-5184
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5184
Project: Hibernate Core
Issue Type: Improvement
Reporter: Steve Ebersole
Fix For: 3.6
Originally ConnectionReleaseMode was added to work around a particular problem of connection "leaking" by JTA containers when used in situations of nested session EJB calls. The connection was not really leaked, but it would appear that way to the JTA resource tracker.
The situation was:
{code}
class EJB1 {
public void doSomething() {
Session s = getCurrentSession();
...
ejb2.doSomethingElse();
// now use the HIbernate session
}
}
class EJB2 {
public void doSomethingElse() {
Session s = getCurrentSession();
// Use the session in a way that requires a Connection...
}
}
{code}
What happens is that EJB1 obtains a Session reference. Just getting a Hibernate Session does not make it get a Connection; the Session delays getting a Connection until it actually needs one. EJB1 then makes the call into EJB2. Again, EJB2 obtains the same Session reference and does some work, so the Session obtains a Connection. Historically that Connection would be held until the Session closed. However that was problematic in this scenario above; to the JTA container it looks like EJB2.doSomethingElse() is leaking the connection outside the transaction boundary (this was many years ago and AFAIU many of these JTA scoping routines have become more sophisticated).
At the time we decided to add the idea of Connection "releasing". However constantly releasing and re-obtaining the Connection can affect performance. Another solution to the problem above is to obtain the Connection up front instead.
So initially I see:
ConnectionAcquisitionMode.AS_NEEDED
ConnectionAcquisitionMode.IMMEDIATELY
--
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
14 years
[Hibernate-JIRA] Created: (HHH-3512) Registration of IdentifierGenerators (short naming)
by Steve Ebersole (JIRA)
Registration of IdentifierGenerators (short naming)
---------------------------------------------------
Key: HHH-3512
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3512
Project: Hibernate Core
Issue Type: New Feature
Components: core, metamodel
Reporter: Steve Ebersole
Assignee: Steve Ebersole
Fix For: 3.4, 4.x
Another way to look at this is to allow configuration of IdentifierGeneratorFactory.
Either allow explicit registration under a short name in config:
<identifier-generator name="sequence-style" class="org.hibernate.id.enhanced.SequenceStyleGenerator"/>
or via an explicit contract:
public interface Registerable {
public String getRegistrationName();
}
public class SequenceStyleGenerator implements IdentifierGenerator, Registerable {
...
public String getRegistrationName() {
return "sequence-style";
}
}
The second, while certainly more verbose, can be used applied to other situations where we want to allow registration moving forward (types, property-accessor, etc).
--
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
14 years
[Hibernate-JIRA] Created: (HHH-2764) EntityType.deepCopy needs to copy for EntityType.DOM4J
by Alan Krueger (JIRA)
EntityType.deepCopy needs to copy for EntityType.DOM4J
------------------------------------------------------
Key: HHH-2764
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2764
Project: Hibernate3
Issue Type: Bug
Affects Versions: 3.2.2
Environment: Hibernate 3.2.2
Reporter: Alan Krueger
Using DOM4J with a set of composite-elements that contains a many-to-one. When loading this from the database, the many-to-one piece of the composite-element is disappearing from the XML. I can see the collection being built and the properties on the elements of the collection being set, but the many-to-one property disappears after that.
Investigating this, it looks like when PersistentElementHolder.getSnapshot is called and a deepCopy is performed, the EntityType.deepCopy method returns the value to be copied rather than copying it. This interacts poorly with the DOM4J tree, since each Element can only have a single Element parent. When the properties are set on this, a detach is performed that yanks the original element out of its parent.
--
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
14 years
[Hibernate-JIRA] Created: (HHH-6916) Not proper array-handling in AbstractQueryImpl.registerParameterBinding
by Christoph Friedl (JIRA)
Not proper array-handling in AbstractQueryImpl.registerParameterBinding
-----------------------------------------------------------------------
Key: HHH-6916
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6916
Project: Hibernate Core
Issue Type: Bug
Components: entity-manager, query-hql, query-sql
Environment: hibernate-entitymanager-3.6.4.Final
Reporter: Christoph Friedl
Priority: Minor
Setting arrays other than Object[] as query parameter throws an exception because of the following code line:
{{else if ( value.getClass().isArray() && value.getClass().equals( Object[].class ) )}}
{{value.getClass().equals( Object[].class )}} just returns true if he given parameter is indeed of type Object[]
e.g. String[].class does not equal Object[].class
A very similar issue has been discussed some time ago - [#HHH-5817]
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[Hibernate-JIRA] Created: (HHH-4739) InheritanceType.SINGLE_TABLE don't work with Postgresql 8.4.1 and postgresql-8.4-701.jdbc3.jar
by Robert Anderson Nogueira de Oliveira (JIRA)
InheritanceType.SINGLE_TABLE don't work with Postgresql 8.4.1 and postgresql-8.4-701.jdbc3.jar
----------------------------------------------------------------------------------------------
Key: HHH-4739
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4739
Project: Hibernate Core
Issue Type: Bug
Components: annotations, core, entity-manager, testsuite
Affects Versions: 3.3.1
Environment: JBoss Seam 2.2.0-GA, PostgreSQL 8.4.1, postgresql-8.4-701.jdbc3.jar
Reporter: Robert Anderson Nogueira de Oliveira
Attachments: main-classes.zip
@Entity
public class FenomenoMetadado implements Serializable {
/**
*
*/
private static final long serialVersionUID = 1L;
@Id @GeneratedValue(strategy = GenerationType.IDENTITY)
private Integer id;
@NotNull
private String nome;
private String descricao;
@OneToMany(fetch = FetchType.LAZY, cascade = CascadeType.ALL, mappedBy = "fenomenoMetadado")
private List<AtributoMetadado> atributosMetadado;
/* Getters and Setters */
}
@Entity
@Inheritance(strategy=InheritanceType.SINGLE_TABLE)
public abstract class AtributoMetadado implements Serializable {
/**
*
*/
private static final long serialVersionUID = 1L;
@Id @GeneratedValue(strategy=GenerationType.IDENTITY)
private Integer id;
@NotNull
private String nome;
@NotNull
private String label;
@NotNull
private Boolean requerido;
@ManyToOne
@JoinColumn(name="fenomenometadado_id", nullable = false)
private FenomenoMetadado fenomenoMetadado;
/* Getters and Setters */
}
@Entity
public class StringMetaDado extends AtributoMetadado {
/**
*
*/
private static final long serialVersionUID = 1L;
}
TestNG:
public class FenomenoMetadadoTests extends SeamTest {
@Test
public void testarCriarRemover() throws Exception {
final FenomenoMetadado instalacaoMetaDado = new FenomenoMetadado();
instalacaoMetaDado.setNome("Instalações");
instalacaoMetaDado.setDescricao("Instalações de Petróleo e Gás");
List<AtributoMetadado> atributos = new ArrayList<AtributoMetadado>();
StringMetaDado att1 = new StringMetaDado();
att1.setLabel("Nome");
att1.setNome("nome");
att1.setRequerido(true);
att1.setFenomenoMetadado(instalacaoMetaDado);
atributos.add(att1);
instalacaoMetaDado.setAtributosMetadado(atributos);
new FacesRequest() {
protected void invokeApplication()
{
EntityManager em = (EntityManager) getValue("#{entityManager}");
try {
em.persist(instalacaoMetaDado);
} catch (Exception e) {
e.printStackTrace();
fail("Hibernate Bug with postgresql-8.4-701.jdbc3.jar");
}
}
}.run();
}
Stacktrace:
Hibernate:
insert
into
FenomenoMetadado
(descricao, nome)
values
(?, ?)
Hibernate:
insert
into
AtributoMetadado
(fenomenometadado_id, label, nome, requerido, DTYPE)
values
(?, ?, ?, ?, 'StringMetaDado')
ERROR [org.hibernate.util.JDBCExceptionReporter] Valor inválido para tipo int : StringMetaDado
javax.persistence.PersistenceException: org.hibernate.exception.DataException: could not insert: [org.domain.geoinfra.entity.StringMetaDado]
at org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:614)
at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:226)
at org.jboss.seam.persistence.EntityManagerProxy.persist(EntityManagerProxy.java:137)
at org.hibernate.search.jpa.impl.FullTextEntityManagerImpl.persist(FullTextEntityManagerImpl.java:93)
at org.jboss.seam.persistence.EntityManagerProxy.persist(EntityManagerProxy.java:137)
at tests.FenomenoMetadadoTests$2.invokeApplication(FenomenoMetadadoTests.java:74)
at org.jboss.seam.mock.AbstractSeamTest$Request.invokeApplicationPhase(AbstractSeamTest.java:646)
at org.jboss.seam.mock.AbstractSeamTest$Request.emulateJsfLifecycle(AbstractSeamTest.java:595)
at org.jboss.seam.mock.AbstractSeamTest$Request.access$100(AbstractSeamTest.java:177)
at org.jboss.seam.mock.AbstractSeamTest$Request$2.doFilter(AbstractSeamTest.java:497)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:40)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:368)
at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:495)
at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:60)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
at org.jboss.seam.mock.AbstractSeamTest$Request.run(AbstractSeamTest.java:491)
at tests.FenomenoMetadadoTests.testarCriarRemover(FenomenoMetadadoTests.java:82)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:644)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:546)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:700)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1002)
at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:137)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:121)
at org.testng.TestRunner.runWorkers(TestRunner.java:908)
at org.testng.TestRunner.privateRun(TestRunner.java:617)
at org.testng.TestRunner.run(TestRunner.java:498)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:329)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:324)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:296)
at org.testng.SuiteRunner.run(SuiteRunner.java:201)
at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:915)
at org.testng.TestNG.runSuitesLocally(TestNG.java:879)
at org.testng.TestNG.run(TestNG.java:787)
at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:75)
at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:127)
Caused by: org.hibernate.exception.DataException: could not insert: [org.domain.geoinfra.entity.StringMetaDado]
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:100)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66)
at org.hibernate.id.insert.AbstractReturningDelegate.performInsert(AbstractReturningDelegate.java:64)
at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2186)
at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2666)
at org.hibernate.action.EntityIdentityInsertAction.execute(EntityIdentityInsertAction.java:71)
at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:279)
at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:321)
at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:204)
at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:130)
at org.hibernate.ejb.event.EJB3PersistEventListener.saveWithGeneratedId(EJB3PersistEventListener.java:49)
at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:154)
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:110)
at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:636)
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:628)
at org.hibernate.engine.EJB3CascadingAction$1.cascade(EJB3CascadingAction.java:28)
at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:291)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:239)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:192)
at org.hibernate.engine.Cascade.cascadeCollectionElements(Cascade.java:319)
at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java:265)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:242)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:192)
at org.hibernate.engine.Cascade.cascade(Cascade.java:153)
at org.hibernate.event.def.AbstractSaveEventListener.cascadeAfterSave(AbstractSaveEventListener.java:479)
at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:357)
at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:204)
at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:130)
at org.hibernate.ejb.event.EJB3PersistEventListener.saveWithGeneratedId(EJB3PersistEventListener.java:49)
at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:154)
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:110)
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:61)
at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:645)
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:619)
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:623)
at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:220)
... 50 more
Caused by: org.postgresql.util.PSQLException: Valor inválido para tipo int : StringMetaDado
at org.postgresql.jdbc2.AbstractJdbc2ResultSet.toInt(AbstractJdbc2ResultSet.java:2759)
at org.postgresql.jdbc2.AbstractJdbc2ResultSet.getInt(AbstractJdbc2ResultSet.java:2003)
at org.jboss.resource.adapter.jdbc.WrappedResultSet.getInt(WrappedResultSet.java:673)
at org.hibernate.id.IdentifierGeneratorFactory.get(IdentifierGeneratorFactory.java:107)
at org.hibernate.id.IdentifierGeneratorFactory.getGeneratedIdentity(IdentifierGeneratorFactory.java:92)
at org.hibernate.id.IdentityGenerator$GetGeneratedKeysDelegate.executeAndExtract(IdentityGenerator.java:98)
at org.hibernate.id.insert.AbstractReturningDelegate.performInsert(AbstractReturningDelegate.java:57)
... 83 more
If I use the jdbc driver postgresql-8.3-605.jdbc3.jar it works fine.
--
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
14 years