[Hibernate-JIRA] Created: (HHH-7059) The DerbyDialect deprecation warning should appear no more, when using one of the version-specific dialects
by Guenther Demetz (JIRA)
The DerbyDialect deprecation warning should appear no more, when using one of the version-specific dialects
------------------------------------------------------------------------------------------------------------
Key: HHH-7059
URL: https://hibernate.onjira.com/browse/HHH-7059
Project: Hibernate ORM
Issue Type: Improvement
Components: core
Affects Versions: 4.1.0, 4.0.1
Reporter: Guenther Demetz
Priority: Minor
Althoug setting a version=specific derby dialect
config.setProperty("hibernate.dialect","org.hibernate.dialect.DerbyTenSevenDialect");
following warning log appears:
@LogMessage(level = WARN)
@Message(value = "The DerbyDialect dialect has been deprecated; use one of the version-specific dialects instead",
id = 430)
This is because currently all versioned DerbyDialects are extending from deprecated super class DerbyDialect
and the constructor of the super class does produce this warning logging regardsless of which concrete type the dialect is.
public DerbyDialect() {
super();
LOG.deprecatedDerbyDialect();
...
}
Please see also:
https://forum.hibernate.org/viewtopic.php?t=1014416
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 7 months
[Hibernate-JIRA] Created: (HHH-7134) Detection of wrong circularity when two tables with same name in different schemas
by Didier Villevalois (JIRA)
Detection of wrong circularity when two tables with same name in different schemas
----------------------------------------------------------------------------------
Key: HHH-7134
URL: https://hibernate.onjira.com/browse/HHH-7134
Project: Hibernate ORM
Issue Type: Bug
Components: core
Affects Versions: 4.1.0
Environment: Hibernate 4.1.0.Release, any database
Reporter: Didier Villevalois
Priority: Blocker
Attachments: 0001-Fix-FKSecondPass-processing-to-take-catalog-and-sche.patch, jpa-test-fkcircularity.zip
There is a problem when two related (in terms of joins) classes have the same name in different schemas.
Attached is a test maven project (run "mvn package" to run the tests) and a fix patch for hibernate-core (based on bc643ddb7cc28db05a7168673746dbf3edee6cf7).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 7 months
[Hibernate-JIRA] Created: (HHH-7212) [Envers] Avoid useless temporary session in Tools.getTargetFromProxy()
by Fabien Le Bars (JIRA)
[Envers] Avoid useless temporary session in Tools.getTargetFromProxy()
----------------------------------------------------------------------
Key: HHH-7212
URL: https://hibernate.onjira.com/browse/HHH-7212
Project: Hibernate ORM
Issue Type: Improvement
Components: envers
Affects Versions: 4.1.1
Environment: Hibernate 4.1.1.Final
H2 1.3.165
Reporter: Fabien Le Bars
Priority: Trivial
The method from Tools class : public static Object getTargetFromProxy(SessionFactoryImplementor sessionFactoryImplementor, HibernateProxy proxy);
uses a temporary session when the proxy is not initialized.
In some cases though, the proxy.getSession() is not null and calling directly proxy.getHibernateLazyInitializer().getImplementation() will return an initialized object even though it was uninitialized right before the call.
Thus changing the following lines
if (!proxy.getHibernateLazyInitializer().isUninitialized()) {
return proxy.getHibernateLazyInitializer().getImplementation();
}
into:
if (!proxy.getHibernateLazyInitializer().isUninitialized()
|| proxy.getHibernateLazyInitializer().getSession() != null) {
return proxy.getHibernateLazyInitializer().getImplementation();
}
avoids useless uses of the temporary session.
The reason I had to made this minor change is that H2 does not handle well temporary sessions when using in-memory database with the initializing script direcly passed in the url (when the temporary session is opening a new connection, it attemps to recreate the whole database and miserably fails).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 7 months
[Hibernate-JIRA] Created: (HHH-7203) IdentityGenerator fails with JOINED Inheritance when inserting entity to PosgtreSQL
by Andrey Vlasov (JIRA)
IdentityGenerator fails with JOINED Inheritance when inserting entity to PosgtreSQL
-----------------------------------------------------------------------------------
Key: HHH-7203
URL: https://hibernate.onjira.com/browse/HHH-7203
Project: Hibernate ORM
Issue Type: Bug
Components: core
Affects Versions: 3.6.10
Environment: Hibernate 3.6.10, PostgreSQL 9.1-901.jdbc4
Reporter: Andrey Vlasov
We have inheritance strategy JOIN in table. Now we want to insert some entity inheriting from this one, and we want PostgreSQL to automatically generate the ID for the new entity.
Hibernate runs IdentityGenerator.GetGeneratedKeysDelegate.executeAndExtract(), which uses "persister.getIdentifierColumnNames()[0]" as identifierColumnName (in Hibernate 3.6.10 it's line 99 in IdentityGenerator) to getGeneratedIdentity.
This identifierColumnName points actually to the child entity identifierColumn. So, this inserting to the parent table fails on getting identifier by wrong column name (a column from the child entity).
This issue is a result of HHH-6580 changes.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 7 months
[Hibernate-JIRA] Created: (HHH-7157) Bi-directional Many-to-One and One-to-Many mapping with EmbeddedId fails
by Clement Pang (JIRA)
Bi-directional Many-to-One and One-to-Many mapping with EmbeddedId fails
------------------------------------------------------------------------
Key: HHH-7157
URL: https://hibernate.onjira.com/browse/HHH-7157
Project: Hibernate ORM
Issue Type: Bug
Components: envers
Affects Versions: 4.1.1
Reporter: Clement Pang
Please see attached test cases on git: https://github.com/panghy/envers-embeddedid-test
Hibernate tries to insert a parameter in the Audit table where there isn't one (6 parameter, trying to insert 7 and more). The issue goes away if we add a @NotAudited annotation to the OneToMany side of the relation (commented out in the code).
Hibernate:
insert
into
PersonTuple_AUD
(REVTYPE, helloWorld, personA_id, personB_id, constant_id, REV)
values
(?, ?, ?, ?, ?, ?)
Mar 8, 2012 2:11:39 AM org.hibernate.engine.jdbc.batch.internal.AbstractBatchImpl release
INFO: HHH000010: On release of batch it still contained JDBC statements
javax.persistence.RollbackException: Error while committing the transaction
at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:90)
at org.hibernate.clementp.EnversTest.testAuditedEmbeddedId(EnversTest.java:55)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:69)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:48)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:292)
at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:76)
at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:182)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:62)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
Caused by: javax.persistence.PersistenceException: org.hibernate.exception.GenericJDBCException: Invalid value "7" for parameter "parameterIndex" [90008-143]
at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1360)
at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1288)
at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:78)
... 31 more
Caused by: org.hibernate.exception.GenericJDBCException: Invalid value "7" for parameter "parameterIndex" [90008-143]
at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:54)
at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:125)
at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:110)
at org.hibernate.engine.jdbc.internal.proxy.AbstractStatementProxyHandler.continueInvocation(AbstractStatementProxyHandler.java:129)
at org.hibernate.engine.jdbc.internal.proxy.AbstractProxyHandler.invoke(AbstractProxyHandler.java:81)
at $Proxy22.setLong(Unknown Source)
at org.hibernate.type.descriptor.sql.BigIntTypeDescriptor$1.doBind(BigIntTypeDescriptor.java:57)
at org.hibernate.type.descriptor.sql.BasicBinder.bind(BasicBinder.java:92)
at org.hibernate.type.AbstractStandardBasicType.nullSafeSet(AbstractStandardBasicType.java:305)
at org.hibernate.type.AbstractStandardBasicType.nullSafeSet(AbstractStandardBasicType.java:300)
at org.hibernate.type.ComponentType.nullSafeSet(ComponentType.java:358)
at org.hibernate.persister.entity.AbstractEntityPersister.dehydrate(AbstractEntityPersister.java:2611)
at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2854)
at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3298)
at org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:88)
at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:362)
at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:354)
at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:275)
at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:326)
at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52)
at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1127)
at org.hibernate.envers.synchronization.AuditProcess.doBeforeTransactionCompletion(AuditProcess.java:157)
at org.hibernate.engine.spi.ActionQueue$BeforeTransactionCompletionProcessQueue.beforeTransactionCompletion(ActionQueue.java:662)
at org.hibernate.engine.spi.ActionQueue.beforeTransactionCompletion(ActionQueue.java:307)
at org.hibernate.internal.SessionImpl.beforeTransactionCompletion(SessionImpl.java:524)
at org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.beforeTransactionCommit(JdbcTransaction.java:105)
at org.hibernate.engine.transaction.spi.AbstractTransactionImpl.commit(AbstractTransactionImpl.java:175)
at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:73)
... 31 more
Caused by: org.h2.jdbc.JdbcSQLException: Invalid value "7" for parameter "parameterIndex" [90008-143]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:327)
at org.h2.message.DbException.get(DbException.java:167)
at org.h2.message.DbException.getInvalidValueException(DbException.java:213)
at org.h2.jdbc.JdbcPreparedStatement.setParameter(JdbcPreparedStatement.java:1254)
at org.h2.jdbc.JdbcPreparedStatement.setLong(JdbcPreparedStatement.java:541)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at org.hibernate.engine.jdbc.internal.proxy.AbstractStatementProxyHandler.continueInvocation(AbstractStatementProxyHandler.java:122)
... 55 more
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 7 months
[Hibernate-JIRA] Created: (HHH-4751) Fix for @embeddedid error: Type not supported: org.hibernate.type.ManyToOneType
by David Coleman (JIRA)
Fix for @embeddedid error: Type not supported: org.hibernate.type.ManyToOneType
--------------------------------------------------------------------------------
Key: HHH-4751
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4751
Project: Hibernate Core
Issue Type: Improvement
Components: envers
Reporter: David Coleman
Priority: Minor
Attachments: IDMetadataGenerator_patch.txt
Hi,
After creating hibernate entities from the legacy database with envers hibernate tool, I noticed the following error occurred on creating an audit tables that has an @EmbeddedId attribute (related to ENVERS-76]:
Caused by: org.hibernate.MappingException: Type not supported: org.hibernate.type.ManyToOneType ..
I found out by looking at the source that the reason it failed was that the property type was not an instance of ImmutableType (not mutable); which was true as the embedded id was a combination of an int and a mutable java data object. I switched the mutable java date object to a immutable joda datetime object using the joda date time hibernate user type to fix the immutable problem.
I also patched IdMetadataGenerator locally to the one attached as hibernate usertypes do not implement the ImmutableType interface; using the method 'isMutable()' should be suffice.
Let me know if this is okay so I can submit the patch.
--
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, 7 months
[Hibernate-JIRA] Created: (HHH-7115) Allow types to have access to target usage data
by Michael Nascimento Santos (JIRA)
Allow types to have access to target usage data
-----------------------------------------------
Key: HHH-7115
URL: https://hibernate.onjira.com/browse/HHH-7115
Project: Hibernate ORM
Issue Type: Improvement
Components: core
Affects Versions: 4.1.0
Environment: hibernate-core:4.1.0.Final
Reporter: Michael Nascimento Santos
In order to being able to support a type hierarchy without having to write a Type per class, access to the actual target property type is needed. This has been hardcoded in org.hibernate.cfg.annotations.SimpleValueBinder for some Hibernate types, such as org.hibernate.type.EnumType and org.hibernate.type.SerializableToBlobType.
Even for the same scenarios above, if one is trying to write his own type for enums or serializables, he has to end up writing a type per target class since the same facility is not provided by Hibernate in a general fashion.
Hence, Hibernate should provide a set of standard properties for type implementations that need actual target usage data. Since some types might use the same property names used by EnumType with a different meaning, injecting these properties for any ParameterizedType might break existing types. Therefore, a ParameterizedType subinterface which also declares the standard property names for this case seems a better design choice.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 7 months
[Hibernate-JIRA] Created: (HHH-5188) Use provided enum type ordinal/string when reading
by Stefan Larsson (JIRA)
Use provided enum type ordinal/string when reading
--------------------------------------------------
Key: HHH-5188
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5188
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.5.1, 3.5.0-CR-2
Reporter: Stefan Larsson
Priority: Minor
Attachments: EnumType.java-typeSafeNullSafeGet.patch
When Hibernate reads a PostgreSQL enum type using ResultSet.getObject(), the JDBC driver returns a driver-specific PGObject object, which preserves both the value of the enum and its type ordinal/string. Hibernate fails with a ClassCastException when it attempts to cast the PGObject into a String in org.hibernate.type.EnumType.nullSafeGet().
The code in org.hibernate.type.EnumType assumes that ResultSet.getObject() will either return a Number or a String, which is not true for the PostgreSQL driver. IMHO it would be better to let the JDBC driver do the conversion using ResultSet.getInt() or getString() instead.
The attached patch allows JBoss AS 6 M3 (Hibernate 3.5.0-CR-2) to read PostgreSQL enums, using JPA, with a a Java enum annotated as @javax.persistence.Enumerated(javax.persistence.EnumType.STRING).
Also, I believe that perhaps ignoring the given enum type causes Issue HHH-4230, where an ordinal enum was stored in character field. ResultSet.getInteger() might work for that one depending on the JDBC driver.
--
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, 7 months
[Hibernate-JIRA] Created: (HHH-4468) Exception when using hibernate as JPA provider: "Found two representations of same collection"
by Håvard Nesvold (JIRA)
Exception when using hibernate as JPA provider: "Found two representations of same collection"
----------------------------------------------------------------------------------------------
Key: HHH-4468
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4468
Project: Hibernate Core
Issue Type: Bug
Components: entity-manager
Affects Versions: 3.3.2
Environment: 3.3.2.GA
Reporter: Håvard Nesvold
I have a J2SE application where I use JPA with Hibernate as persistence provider. The versions of the required hibernate jars that I use are:
hibernate3.jar (3.3.2.GA)
hibernate-annotations.jar (3.4.0.GA)
hibernate-commons-annotations.jar (3.1.0.GA)
hibernate-entitymanager.jar (3.4.0.GA)
I have an entity where i have a bidirectional One-To-Many mapping. This is initialized to an empty list, something that clearly is allowed according to the JPA 1.0 spec.
i.e. I have:
in class Parent:
@OneToMany(mappedBy="parent", cascade = CascadeType.ALL)
private List<Child> children = ArrayList<Child>();
class Child:
@ManyToOne
@JoinColumn(name="PARENT_ID")
private Parent parent;
A certain sequence of actions result in a HibernateException being thrown (wrapped by JPA in a RollbackException):
* Obtain a new EntityManager
* Begin a transaction
* Fetch a Parent entity from the entity manager (this exists in the db), call this e.
* Apply an EntityManager.remove() on e
* Commit the transaction
* Begin a transaction
* Apply an EntityManager.persist() on e
* Commit the transaction
The exception is thrown on the last commit():
Code:
Caused by: org.hibernate.HibernateException: Found two representations of same collection: Parent.children
at org.hibernate.engine.Collections.processReachableCollection(Collections.java:176)
at org.hibernate.event.def.FlushVisitor.processCollection(FlushVisitor.java:60)
at org.hibernate.event.def.AbstractVisitor.processValue(AbstractVisitor.java:124)
...
I have tried to flush(), clear(), and pretty much everything on the entity manager (event fetching the Hibernate Sesssion and clearing this) - the only thing that helps is creating a new one before attempting the last transaction.
Moreover, after some investigation, the persisted entity actually seems to be persisted correctly - despite the exception (this also seems to hold true for any cascaded persists), perhaps the only erroneous thing here is the fact that an exception is thrown when it really should not?
--
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, 7 months
[Hibernate-JIRA] Created: (ANN-808) @Enumerated(ORDINAL) does not work on VARCHAR columns
by Eduardo Costa (JIRA)
@Enumerated(ORDINAL) does not work on VARCHAR columns
-----------------------------------------------------
Key: ANN-808
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-808
Project: Hibernate Annotations
Issue Type: Bug
Affects Versions: 3.3.1.GA
Environment: Tested on Postgres, but the problem should be reproductible on any DB vendor
Reporter: Eduardo Costa
Copied from http://forum.hibernate.org/viewtopic.php?t=995698:
==========
Suppose I have this enum:
public enum Status { OK, NOK, NOT_APPLICABLE }
And this property:
@Column(name = "status")
@Enumerated(EnumType.ORDINAL)
private Status status;
And this table (legacy, CANNOT be changed):
CREATE TABLE tb_xxx (
id bigint NOT NULL,
status character varying(1) NOT NULL,
)
It leads to this exception:
java.lang.IllegalArgumentException: No enum const class mypkg.Status.1
java.lang.Enum.valueOf(Enum.java:196)
org.hibernate.type.EnumType.nullSafeGet(EnumType.java:110)
Taking a look at EnumType.java, it is clear that Hibernate imposes ordinal stored as number and name stored as varchar.
=========
IMHO, this is a "specification gap": JPA does not consider what to do if I'm trying to map a legacy enumerated value. Since I'm defining @Enumerated as "ordinal" and I have "0", "1", "2" on my database, I believe Hibernate should consider what I'm defining, not what an ancient DBA defined. Otherwise, I can't map this using only Hibernate Annotations/JPA (BTW, this code works with TopLink, only changing JPA provider on persistence.xml)
--
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, 7 months