[Hibernate-JIRA] Created: (HHH-5376) Tests contain invalid SQL
by Fred Toussi (JIRA)
Tests contain invalid SQL
-------------------------
Key: HHH-5376
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5376
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 3.5.x
Environment: Using HSQLDB 2.0.1 and Hibernate trunk (12 July 2010)
Reporter: Fred Toussi
These create table statements declare both primary key and unique constraints on the same set of columns. This is against the SQL standard and will fail with most databases.
public class DerivedIdentitySimpleParentSimpleDepTest extends TestCase {
22:52:06,265 ERROR SchemaExport:386 - Unsuccessful: create table MedicalHistory (lastupdate date, FK varchar(255) not null, primary key (FK), unique (FK))
22:52:06,265 ERROR SchemaExport:387 - a UNIQUE constraint already exists on the set of columns in statement [create table MedicalHistory (lastupdate date, FK varchar(255) not null, primary key (FK), unique (FK))]
public class DerivedIdentityIdClassParentSameIdTypeIdClassDepTest extends TestCase {
public void testOneToOneExplicitJoinColumn() throws Exception {
23:16:18,328 DEBUG SchemaExport:415 -
create table MedicalHistory (
FK1 varchar(255) not null,
FK2 varchar(255) not null,
primary key (FK1, FK2),
unique (FK1, FK2)
)
23:16:18,328 ERROR SchemaExport:386 - Unsuccessful: create table MedicalHistory (FK1 varchar(255) not null, FK2 varchar(255) not null, primary key (FK1, FK2), unique (FK1, FK2))
23:16:18,328 ERROR SchemaExport:387 - a UNIQUE constraint already exists on the set of columns in statement [create table MedicalHistory (FK1 varchar(255) not null, FK2 varchar(255) not null, primary key (FK1, FK2), unique (FK1, FK2))]
--
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 years
[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
12 years
[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
12 years
[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
12 years
[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
12 years
[Hibernate-JIRA] Created: (HHH-3809) Improve Memory Management when Post Commit Listeners are enabled
by Shawn Clowater (JIRA)
Improve Memory Management when Post Commit Listeners are enabled
----------------------------------------------------------------
Key: HHH-3809
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3809
Project: Hibernate Core
Issue Type: Improvement
Components: core
Affects Versions: 3.3.1
Environment: N/A
Reporter: Shawn Clowater
This is somewhat related to the QueryCache behavior reported under http://opensource.atlassian.com/projects/hibernate/browse/HHH-3028
In this particular case however, it is the fact that when the session factory is configured to have post commit listeners it prevents the garbage collection of any entity that is modified during the session due to the fact that it is referenced in the executions list in the ActionQueue class. This makes any type of memory management by flushing/clearing the session ineffective if you're in the middle of a large batch that is inserting or updating a large amount of data.
i.e in our case we have 4 entities out of possibly 300 or so that we want to notify external systems if they change. However, by simply having the listeners defined they essentially block the remaining entities in the executions.
A potential workaround I guess might be to keep 2 session factories around with a different set of listeners but that seems a bit dirty.
There are 2.5 potential ways that I can think of that might address this.
1 - Have some sort of flag on the session to disable the post commit listeners. The onus would be on the user of the session to disable the listeners in the case where they know they aren't modifying anything that will need post commit handling.
2 - Add the ability to configure the post commit listeners by entity
a)With polymorphism - i.e. you could add a listener based on Object.class and it would apply to all entities and would behave much like it does now. You could also configure to Animal.class and would include Cat and Dog.
b)Without polymorphism - you could add a listener based on a specific entity class and it would only apply to that particular one. You would have an option to specify a null entity and it would default to what is there today.
In my miind, 2a is probably the best albeit slightly more complex to implement but I think would be a good value add.
I don't mind submitting a patch assuming that I'm not so far in left field that I should be committed.
--
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 years, 1 month
[Hibernate-JIRA] Created: (ANN-630) @ManyToMany and @Index
by Peter K. Guldbæk (JIRA)
@ManyToMany and @Index
----------------------
Key: ANN-630
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-630
Project: Hibernate Annotations
Issue Type: Bug
Affects Versions: 3.3.0.ga
Environment: Windows Vista
java version "1.5.0_11"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03)
Java HotSpot(TM) Client VM (build 1.5.0_11-b03, mixed mode)
Reporter: Peter K. Guldbæk
I have trouble adding an index to a column of a table which is part of a many-to-many property mapping. The following example causes a NullPointerException when generating the DDL (the exception can be seen at the end of my post):
@Entity @Table(name="usr")
public class User implements Serializable
{
@Id @GeneratedValue(strategy=GenerationType.AUTO)
public Integer id;
@ManyToMany(targetEntity=Target.class, cascade={})
@Index(name="fkey_usr_target", columnNames="usr_id")
@JoinTable(name="usr_target",
joinColumns=@JoinColumn(name="usr_id"),
inverseJoinColumns=@JoinColumn(name="target_id"))
public Collection<Target> targets;
}
@Entity @Table(name="target")
public class Target implements Serializable
{
@Id @GeneratedValue(strategy=GenerationType.AUTO)
public Integer id;
@Basic
public String myValue;
}
NullPointerException thrown when an @Index annotation is used with a @ManyToMany:
java.lang.NullPointerException
at org.hibernate.cfg.AnnotationBinder.processElementAnnotations(AnnotationBinder.java:1594)
at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:733)
at org.hibernate.cfg.AnnotationConfiguration.processArtifactsOfType(AnnotationConfiguration.java:498)
at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:277)
at org.hibernate.cfg.Configuration.buildMappings(Configuration.java:1115)
at org.hibernate.tool.ant.ConfigurationTask.getConfiguration(ConfigurationTask.java:56)
at org.hibernate.tool.ant.HibernateToolTask.getConfiguration(HibernateToolTask.java:299)
at org.hibernate.tool.ant.Hbm2DDLExporterTask.execute(Hbm2DDLExporterTask.java:45)
at org.hibernate.tool.ant.HibernateToolTask.execute(HibernateToolTask.java:183)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
at sun.reflect.GeneratedMethodAccessor19.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:357)
at org.apache.tools.ant.Target.performTasks(Target.java:385)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329)
at org.apache.tools.ant.Project.executeTarget(Project.java:1298)
at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1181)
at org.apache.tools.ant.Main.runBuild(Main.java:698)
at org.apache.tools.ant.Main.startAnt(Main.java:199)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)
--
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 years, 1 month