[Hibernate-JIRA] Created: (ANN-848) Bidirectional Polymorphism
by Yong Joo Jeong (JIRA)
Bidirectional Polymorphism
--------------------------
Key: ANN-848
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-848
Project: Hibernate Annotations
Issue Type: New Feature
Components: binder
Affects Versions: 3.4.0.GA
Environment: 3.4.0.GA, Any database
Reporter: Yong Joo Jeong
I'm trying to implement bidirectional polymorphic class.
Code:
public class Order{
...
@Any( metaColumn = @Column( name = "item_type" ), fetch=FetchType.EAGER )
@AnyMetaDef(
idType = "long",
metaType = "string",
metaValues = {
@MetaValue( value = "ItemA", targetEntity = ItemA.class ),
@MetaValue( value = "ItemB", targetEntity = ItemB.class )
} )
@JoinColumn( name = "item_id" )
Object item;
...
}
And trying to do somthing like the following
Code:
public class ItemA {
@OneToAny // like @OneToMany; in Order table there are "item_id" and "item_type" fields to distinguish ItemA and ItemB
List<Order> orders;
...
}
RoR support this kind of relationship, but I can't find it from Hibernate.
Inheritance with "Table per class" is not an option since it does not support the IDENTITY generator strategy.
Any solution for this?
--
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: (HBX-1092) hbm2doc with graphing fails on MacOSX
by Avram Cherry (JIRA)
hbm2doc with graphing fails on MacOSX
-------------------------------------
Key: HBX-1092
URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-1092
Project: Hibernate Tools
Issue Type: Bug
Components: hbm2doc
Affects Versions: 3.2.0.GA, 3.2.2
Reporter: Avram Cherry
In the method org.hibernate.tool.hbm2x.DocExporter.dotToFile, the portions of the command passed to Runtime.exec() are being passed to an escape(String) method that optionally adds quotes to the executable file path and the path to the input file, but only if the OS is not linux. MacOSX is not linux, but adding quotes causes exec() to fail.
The solution is to change the following statement:
String exeCmd = escape(dotExeFileName) + " -T" + getFormatForFile(outFileName) + " " + escape(dotFileName) + " -o " + escape(outFileName);
to:
String[] exeCmd = new String[] {dotExeFileName, " -T", getFormatForFile(outFileName), dotFileName, " -o ", outFileName};
If you pass the command and arguments as separate strings within an array to Runtime.exec() you do not need to quote filenames, regardless of platform.
A (potentially very harmful) workaround is to pass -Dos.name=Linux to the VM.
Please note that I've checked both the 3.2 branch and trunk and both contain the same problem.
--
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-5265) @Formula adds a this_. prefix to an SQL function
by Matthias Bosshard (JIRA)
@Formula adds a this_. prefix to an SQL function
------------------------------------------------
Key: HHH-5265
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5265
Project: Hibernate Core
Issue Type: Bug
Components: annotations, core
Affects Versions: 3.5.2
Environment: Hibernate 3.5.2, with a SQL Anywhere 10 and the org.hibernate.dialect.SybaseDialect
Reporter: Matthias Bosshard
With Hibernate 3.5.2 the ISNULL/COALESCE SQL statement in the following @Formula is prefixed with a this_. An so its no valid SQL.
The annotation:
@Formula( "(SELECT ISNULL ( (SELECT 1 WHERE EXISTS (SELECT * FROM org.usertable as user WHERE user.user_id = user_id)), 0))" )
The SQL part for this formula:
(SELECT *this_.ISNULL* ( (SELECT 1 WHERE EXISTS (SELECT * FROM org.usertable as user WHERE user.user_id = this_.user_id)), 0)) as formula8_1_,
-> thats invalid SQL
In Hibernate 3.5.1 the SQL is pretty the same, but without this_. before ISNULL.
(SELECT *ISNULL* ( (SELECT 1 WHERE EXISTS (SELECT * FROM org.usertable as user WHERE user.user_id = this_.user_id)), 0)) as formula8_1_,
--
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-3824) OneToOne join by Non-primary key column throws PropertyAccessException when join column is String
by sathish (JIRA)
OneToOne join by Non-primary key column throws PropertyAccessException when join column is String
-------------------------------------------------------------------------------------------------
Key: HHH-3824
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3824
Project: Hibernate Core
Issue Type: Bug
Components: query-criteria, query-hql
Affects Versions: 3.3.1
Environment: Microsoft SQL server 2005, Hibernate 3.3.1
Reporter: sathish
Attachments: trace.txt
When i try to join 2 entities by OneToOne using a Non-primary key column, it throws the following exception:
org.hibernate.PropertyAccessException: could not get a field value by reflection getter of com.xxx.domain.Inventory.sku
Caused by: java.lang.IllegalArgumentException: Can not set java.lang.String field com.inwk.estore.server.domain.Inventory.sku to java.lang.Integer
[Full stacktrace attached]
sku is the Non-primary key String join column by which im trying to do a OneToOne join between Item and Inventory entity.
Apparently its trying to interpret Sku as an Integer column. Adding columnDefinition as VARCHAR/String doesn't help either
Mappings for Item and Inventory are below:
class Item{
@Id
Long id;
@Column
String sku;
//some more properties
@OneToOne(optional = true)
@JoinColumn(name = "sku", referencedColumnName = "sku", insertable = false, updatable = false)
Inventory inventory;
}
class Inventory{
@Id
Long id
@Column
String sku
@Column
Long quantity;
}
--
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-5136) map-key-column is broken
by Harald Wellmann (JIRA)
map-key-column is broken
------------------------
Key: HHH-5136
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5136
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 3.5.1
Environment: Hibernate 3.5.1, PostgreSQL 8.4.3
Reporter: Harald Wellmann
Priority: Critical
I have an entity with a Map<String, Embeddable> with unexpected behaviour. The problem is that annotation mappings and the equivalent XML mappings yield different results. (For brevity, I'm leaving out the getters and setters and the SQL constraints in the following examples.)
Here is my Embeddable:
{code:java}
@Embeddable
public class LocalizedString
{
private String language;
private String text;
}
{code}
And this is the containing entity:
{code:java}
@Entity
public class Amenity
{
@Id
@Column(name = "amenity_id")
@GeneratedValue
private long id;
@ElementCollection
@CollectionTable(name = "amenity_name", joinColumns = @JoinColumn(name = "amenity_id"))
@MapKeyColumn(name = "language_map_key")
private Map<String, LocalizedString> names = new HashMap<String, LocalizedString>();
}
{code}
Hibernate generates the following collection table:
{code:sql}
CREATE TABLE amenity_name
(
amenity_id bigint NOT NULL,
"language" character varying(255),
"text" character varying(255),
language_map_key character varying(255) NOT NULL
)
{code}
Now when replacing the annotations by the following XML mapping
{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<entity-mappings version="2.0"
xmlns="http://java.sun.com/xml/ns/persistence/orm" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence/orm http://java.sun.com/xml/ns/persistence/orm_2_0.xsd">
<entity class="Amenity">
<attributes>
<id name="id">
<column name="amenity_id"/>
<generated-value />
</id>
<element-collection name="names">
<map-key-column name="language_map_key" />
<collection-table name="amenity_name">
<join-column name="amenity_id" referenced-column-name="amenity_id"/>
</collection-table>
</element-collection>
</attributes>
</entity>
<embeddable class="LocalizedString">
<attributes>
<basic name="language"></basic>
<basic name="text"></basic>
</attributes>
</embeddable>
</entity-mappings>
{code}
the generated SQL looks like this:
{code:sql}
CREATE TABLE amenity_names
(
amenity_amenity_id bigint NOT NULL,
"language" character varying(255),
"text" character varying(255),
names_key character varying(255) NOT NULL
)
{code}
It seems that the map-key-column and collection-table settings are simply ignored.
Another question: The column language_map_key is actually redundant, I would like to use the language column as map key instead. The JPA 2.0 spec is a bit vague on this case. When the map value is an entity, @MapKey can be used to select a property of the entity value as map key, but it is not clear to me whether the spec supports supressing the separate key column when the map value is an embeddable.
I tried using @MapKeyColumn(name="language"), but then Hibernate complained about a duplicate column.
Eclipselink (the version contained in Glassfish v3) accepts this usage and suppresses the duplicate column, i.e. the join table has the form
{code:sql}
CREATE TABLE amenity_name
(
amenity_id bigint NOT NULL,
"language" character varying(255),
"text" character varying(255)
)
{code}
--
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-4581) Embedded objects in criteria API does not work
by Jaroslaw Lewandowski (JIRA)
Embedded objects in criteria API does not work
----------------------------------------------
Key: HHH-4581
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4581
Project: Hibernate Core
Issue Type: Bug
Components: query-criteria
Affects Versions: 3.5.0-Beta-2
Reporter: Jaroslaw Lewandowski
It not possible to use Embedded attribute in Criteria API. E.g. having the following entity
@Entity
class Client {
@Embedded
private Name name;
}
@Embeddable
public class Name implements Serializable {
@Basic
private String firstName;
@Basic
private String lastName;
}
The following throws an exception
CriteriaBuilder cb = em.getCriteriaBuilder();
CriteriaQuery<ClientCard> cq = cb.createQuery(Client.class);
Root<ClientCard> root = cq.from(ClientCard.class);
cq.where(cb.equal(root.get(Client_.name).get(Name_.firstName)), "blah");
em.createQuery(cq).getResultList();
Saying that Name is not managed entity:
Caused by: java.lang.IllegalArgumentException: Not an managed type: class com.phorest.memento.server.domain.Name
at org.hibernate.ejb.metamodel.MetamodelImpl.managedType(MetamodelImpl.java:171)
at org.hibernate.ejb.criteria.JoinImpl.<init>(JoinImpl.java:54)
at org.hibernate.ejb.criteria.FromImpl.constructJoin(FromImpl.java:193)
at org.hibernate.ejb.criteria.FromImpl.join(FromImpl.java:176)
at org.hibernate.ejb.criteria.FromImpl.join(FromImpl.java:169)
at org.hibernate.ejb.criteria.FromImpl.get(FromImpl.java:559)
--
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-3007) Unchanged persistent set gets marked dirty on session.merge()
by Lars Koedderitzsch (JIRA)
Unchanged persistent set gets marked dirty on session.merge()
-------------------------------------------------------------
Key: HHH-3007
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3007
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.5
Reporter: Lars Koedderitzsch
Persistent sets are marked dirty on session.merge() even if there have been no changes to the collection.
This is especially painful when the collection is immutable and results in an "changed an immutable collection instance" exception on flush.
I tracked the behaviour down a bit and believe the problem to be in CollectionType.replace().
Here the passed in orginal PersistentSet is replaced by a plain HashSet in this line:
Object result = target == null || target == original ? instantiateResult( original ) : target;
The "result" object (HashSet) is then passed to the CollectionType.replaceElements() method (instead of the original PersistentSet).
In CollectionType.replaceElements() the code to clear the dirty state of the collection does not execute anymore, because the passed-in "original" collection is the described HashSet and *not* the original PersistentSet.
This way the PersistentSet remains marked dirty.
A workaround is to manually clear the dirty state of an immutable collection after merge but before flush.
--
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, 1 month
[Hibernate-JIRA] Created: (HSEARCH-513) Hibernate Search 3.2.0.CR1 listeners cause long delays when indexing entities saved in different transactions
by Florin Haizea (JIRA)
Hibernate Search 3.2.0.CR1 listeners cause long delays when indexing entities saved in different transactions
-------------------------------------------------------------------------------------------------------------
Key: HSEARCH-513
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-513
Project: Hibernate Search
Issue Type: Bug
Affects Versions: 3.2.0.CR1
Environment: Hibernate 3.5.1-Final
Spring 3.0.2
MySQL Connector 5.1.6
Reporter: Florin Haizea
Attachments: HibernateSearchJira.zip
I have 3 entities Person, Event and ParentOfBirthEvent. I save about 8000 Person objects in batches of 20, each batch is being saved in a different transaction. After a sufficient number of entities have been persisted (the saving and indexing of initial batches takes between150ms and 500ms) the indexing of the entities that are saved in some of the following batches takes a very large amount of time (sometime even minutes for a whole batch).
The problem is that in order for these delays to appear there has to be a certain relationship between the objects saved in the current batch and objects saved in previous batches. The only way in which I can reproduce this 100% is by importing a file (which was submitted by one of the users of our app), creating entities based on the data in that file and saving the entities in batches of 20. When I reach batch number 273 or so the indexing starts taking a lot of time.
If I removed the @IndexedEmbedded annotation from the "parent" field in the ParentOfBirthEvent class the problem is solved. Also, if I removed all the hibernate search listeners from the sessionFactory the problem is solved.
--
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, 1 month