[Hibernate-JIRA] Commented: (HHH-1829) Allow join on any property using property-ref
by Mathieu Gervais (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1829?page=c... ]
Mathieu Gervais commented on HHH-1829:
--------------------------------------
Hi Steve.
Thanks for looking into this issue.
1) I'm from the same company has Robert Field who recently commented. In case that helps, I've ran and API diff (using CLIRR) on the patched (HHH-1829-mwinkels.patch) vs unpatched 3.2.5.ga. Here are the results:
ERROR: 7004: org.hibernate.hql.ast.exec.AbstractStatementExecutor: In method 'protected java.lang.String generateIdSubselect(org.hibernate.persister.entity.Queryable)' the number of arguments has changed
INFO: 7011: org.hibernate.mapping.DependantValue: Method 'public void createForeignKeyOfEntity(java.lang.String)' has been added
INFO: 7011: org.hibernate.mapping.DependantValue: Method 'public java.util.Iterator getReferencedColumns()' has been added
INFO: 7011: org.hibernate.mapping.DependantValue: Method 'public java.lang.String getReferencedPropertyName()' has been added
INFO: 7011: org.hibernate.mapping.DependantValue: Method 'public void setReferencedPropertyName(java.lang.String)' has been added
ERROR: 7006: org.hibernate.mapping.Join: Return type of method 'public org.hibernate.mapping.KeyValue getKey()' has been changed to org.hibernate.mapping.DependantValue
ERROR: 7005: org.hibernate.mapping.Join: Parameter 1 of 'public void setKey(org.hibernate.mapping.KeyValue)' has changed its type to org.hibernate.mapping.DependantValue
INFO: 7011: org.hibernate.persister.entity.AbstractEntityPersister: Method 'public void addIdentifierColumns(java.lang.String, org.hibernate.sql.SelectFragment)' has been added
ERROR: 7004: org.hibernate.persister.entity.AbstractEntityPersister: In method 'public void delete(java.io.Serializable, java.lang.Object, java.lang.Object, org.hibernate.engine.SessionImplementor)' the number of arguments has changed
INFO: 7011: org.hibernate.persister.entity.AbstractEntityPersister: Method 'public java.lang.String[] getIdentifierColumnNames(int)' has been added
INFO: 7011: org.hibernate.persister.entity.AbstractEntityPersister: Method 'protected java.io.Serializable getIdentifierForJoin(int, java.io.Serializable, java.lang.Object[])' has been added
INFO: 7011: org.hibernate.persister.entity.AbstractEntityPersister: Method 'public org.hibernate.type.Type getIdentifierType(int)' has been added
INFO: 7011: org.hibernate.persister.entity.AbstractEntityPersister: Method 'protected java.lang.String[] getJoinColumnNames(int)' has been added
ERROR: 7004: org.hibernate.persister.entity.EntityPersister: In method 'public void delete(java.io.Serializable, java.lang.Object, java.lang.Object, org.hibernate.engine.SessionImplementor)' the number of arguments has changed
ERROR: 7012: org.hibernate.persister.entity.Loadable: Method 'public java.lang.String[] getIdentifierColumnNames(int)' has been added to an interface
ERROR: 7012: org.hibernate.persister.entity.Queryable: Method 'public void addIdentifierColumns(java.lang.String, org.hibernate.sql.SelectFragment)' has been added to an interface
ERROR: 7004: org.hibernate.persister.entity.Queryable: In method 'public java.lang.String[] getIdentifierColumnNames()' the number of arguments has changed
INFO: 7011: org.hibernate.persister.entity.SingleTableEntityPersister: Method 'public void addIdentifierColumns(java.lang.String, org.hibernate.sql.SelectFragment)' has been added
INFO: 7011: org.hibernate.persister.entity.SingleTableEntityPersister: Method 'public java.lang.String[] getIdentifierColumnNames(int)' has been added
INFO: 7011: org.hibernate.persister.entity.SingleTableEntityPersister: Method 'protected java.io.Serializable getIdentifierForJoin(int, java.io.Serializable, java.lang.Object[])' has been added
INFO: 7011: org.hibernate.persister.entity.SingleTableEntityPersister: Method 'public org.hibernate.type.Type getIdentifierType(int)' has been added
INFO: 7011: org.hibernate.persister.entity.SingleTableEntityPersister: Method 'protected java.lang.String[] getJoinColumnNames(int)' has been added
2)
> The issue is that I really just have no idea about the state of the attached patches. Which are pertinent? Which are valid?
Here is my understanding of the current state, from comments on this Jira and the attachments history @ http://opensource.atlassian.com/projects/hibernate/secure/ManageAttachmen... :
-In Nov/06 Andrew Seales posted an initial patch with no tests.
-Subsequently, Maarten Winkels posted tests commenting "I think they show very basic cases where the functionality is needed.".
-Following the test cases submitted by Maarten, Andrew noted issues with his patch, and said he would post a fixed one, which he didn't do (Andrew didn't post anything else since then)
-In Feb/07, Maarten posted a patch ( HHH-1829-mwinkels.patch ) passing all tests, including the ones attached to this issue. His comment are @ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1829?focuse...
- We used that patch with success. No one reported issues with that patch on this jira item.
So in summary, I'd say you should only look at the later patch ( HHH-1829-mwinkels.patch ).
We understand your concerns about applying a patch that doesn't seem polished enough (Maarten mentioned that "the code is not very clean"). I guess ideally at this point there would be collaboration between someone with hibernate internals deep expertise and the author(s) of the patches to iron out any issues and raise the confidence level. Maybe the first step would be for the patch to be reviewed by someone from the hibernate team to indicate any issues / concerns with it, and then the community can address those? Otherwise, can you let us know what we can do to help?
Thanks.
> Allow join on any property using property-ref
> ---------------------------------------------
>
> Key: HHH-1829
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1829
> Project: Hibernate Core
> Issue Type: New Feature
> Components: metamodel
> Affects Versions: 3.2.0 cr1, 3.2.0.cr2
> Reporter: Maarten Winkels
> Assignee: Steve Ebersole
> Attachments: AbstractJoinTest.java, HHH-1829-mwinkels.patch, hhh-1829.patch, JoinNoPropertyRefTest.java, JoinPropertyRefTest.java, Person.hbm.xml, Person.java, PersonNoPropertyRef.hbm.xml
>
>
> Currently joining tables for one class (uing the <join...> tag) is only supported for the id property. The property-ref is allowed on the <key..> tag inside the <join..> tag, but this is ignored.
--
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, 9 months
[Hibernate-JIRA] Commented: (HHH-1829) Allow join on any property using property-ref
by Robert Field (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1829?page=c... ]
Robert Field commented on HHH-1829:
-----------------------------------
A project I am associated with has been successfully using HHH-1829-mwinkels.patch with 3.2.5 for a year now. It was applied by hand, because the patch command didn't work cleanly with that hibernate version.
There are only a couple of minor problems with it that I can see.
1) It seems to always use outer join when joining on a non-primary key, which doesn't really matter for the query we are doing.
2) Another project team that was using our patched jar, found an API difference between the patch and unpatched hibernate.
> Allow join on any property using property-ref
> ---------------------------------------------
>
> Key: HHH-1829
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1829
> Project: Hibernate Core
> Issue Type: New Feature
> Components: metamodel
> Affects Versions: 3.2.0 cr1, 3.2.0.cr2
> Reporter: Maarten Winkels
> Assignee: Steve Ebersole
> Attachments: AbstractJoinTest.java, HHH-1829-mwinkels.patch, hhh-1829.patch, JoinNoPropertyRefTest.java, JoinPropertyRefTest.java, Person.hbm.xml, Person.java, PersonNoPropertyRef.hbm.xml
>
>
> Currently joining tables for one class (uing the <join...> tag) is only supported for the id property. The property-ref is allowed on the <key..> tag inside the <join..> tag, but this is ignored.
--
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, 9 months
[Hibernate-JIRA] Created: (HHH-3719) Javassist fails to instrument valid classes in certain cases
by Paul Pogonyshev (JIRA)
Javassist fails to instrument valid classes in certain cases
------------------------------------------------------------
Key: HHH-3719
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3719
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.1
Environment: Javassist 3.4.GA (also tested with 3.9.GA)
Reporter: Paul Pogonyshev
Priority: Minor
In certain cases Javassist fails with the following message: "duplicate method: getId in org.hibernate.proxy.HibernateProxy_$$_javassist_0".
I was able to trace the problem down to the following simple case.
public interface Identifiable <Type>
{ Type getId (); }
public interface Entity extends Identifiable <Long>
{ Long getId (); }
public class EntityImpl implements Entity
{
private Long id;
public Long getId ()
{ return id; }
void setId (Long id)
{ this.id = id; }
}
<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
"-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<hibernate-mapping>
<class name="EntityImpl"
proxy="Entity">
<id name="id"/>
</class>
</hibernate-mapping>
Note that at least generics in definition of Identifiable interface and specifying proxy interface in the mapping seems important. Easy workaround seems to just not explicitly redefine getId() in Entity interface, i.e. just keep the one (same one) gotten from Identifiable. However, _finding_ this workaround was by no means easy.
As I know, Java compiler removes generics information from compiled code, so the two methods might indeed appear different (i.e. as Objecte getId() and Long getId() correspondingly). Maybe Javassist could just disable duplicate method checks in generated classes for the cases when _both_ methods come from the wrapped class?
I'm not sure this is the right tracker, but I couldn't find one for Javassist.
--
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, 9 months
[Hibernate-JIRA] Created: (HHH-4448) SchemaExport - Provide a constant naming generation for constraints
by Marcelo Felix (JIRA)
SchemaExport - Provide a constant naming generation for constraints
-------------------------------------------------------------------
Key: HHH-4448
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4448
Project: Hibernate Core
Issue Type: Improvement
Reporter: Marcelo Felix
We have a frequent database maintenance problem - Hibernate doesn't gererate a constant name for Unique and Primary keys. The name of a given key becomes different everytime it's recreated. Hence, if the schema generation and database creation is part os the build (as in our case), this problem makes the build irreproducible (different builds could generate differente database schemas).
At the moment, when we need to modify a unique key, for example, we have to search its name in a Oracle system table. To worsen, in production environments we don't have such access.
I noticed that hbm2ddl generates Foreign Key constraints based on hashcodes.
Is it possible to improve Hibernate, to do the same naming generation for Unique and Primary Keys?
The final result would be like this:
create table USER (
ID number(19,0) not null,
COLUMN1 varchar2(255 char),
COLUMN2 varchar2(255 char),
constraint PK_27E3CBF73AEE0F primary key (ID),
constraint UK_27E3CB143B677E unique (COLUMN1, COLUMN2)
);
Perhaps would be necessary to activate this feature according to the dialect.
I also noticed related requests, like HB-1245 and HHH-3296, but I think that my request is a lot more easier to accomplish - we just need a constant name, whatever it would be.
If it seems reasonable I could develop and send a 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
14 years, 9 months
[Hibernate-JIRA] Created: (ANN-548) Joins break when using composite primary key classes
by Vincent Jenks (JIRA)
Joins break when using composite primary key classes
----------------------------------------------------
Key: ANN-548
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-548
Project: Hibernate Annotations
Type: Bug
Versions: 3.2.1, 3.2.2
Environment: JBoss 4.0.5.GA w/ Hibernate 3.2.2 and Annoations 3.2.2 (from SVN). Also reproduced w/ JBoss 4.0.5.GA w/ stock annotations, hibernate, and entity manager, unmodified. The attached test-case was run against MSSQL 2000 but is trivial to point at another database. The issue was also reproduced on a OpenEdge Progress 10.1A database.
Reporter: Vincent Jenks
Attachments: CarBean.java, Carz.java, Lotz.java
Joins break when using composite primary key classes
JBoss 4.0.5.GA w/ Hibernate 3.2.2 and Annoations 3.2.2 (from SVN). Also reproduced w/ JBoss 4.0.5.GA w/ stock annotations, hibernate, and entity manager, unmodified. The attached test-case was run against MSSQL 2000 but is trivial to point at another database. The issue was also reproduced on a OpenEdge Progress 10.1A database.
In a case where there are composite keys on one (or each) side of a relationship, Hibernate cannot join the entities together if all of the primary key fields are not used in the relationship.
A (very) simple example, two entities Carz and Lotz (pardon the names, it's simply cars and car lots):
@Entity
@Table(name="car")
public class Carz implements Serializable
{
@Id
private Integer id;
@Column(name="make", nullable=false)
private String make;
@Column(name="model", nullable=false)
private String model;
@Column(name="manufactured", nullable=false)
@Temporal(TemporalType.TIMESTAMP)
private Date manufactured;
@ManyToOne(fetch=FetchType.LAZY)
@JoinColumns //Hibernate docs state that @JoinColumns must be used since Lotz has composite PK, a single @JoinColumn does not deploy anyhow
({
@JoinColumn(name="loc_code", referencedColumnName="loc_code", insertable=false, updatable=false)
})
private Lotz lot;
...........................
}
@Entity
@Table(name="lot")
public class Lotz implements Serializable
{
@EmbeddedId
protected LotzPK lotPK;
@Column(name="name", nullable=false)
private String name;
@Column(name="location", nullable=false)
private String location;
@OneToMany(mappedBy="lot", fetch=FetchType.LAZY, cascade=CascadeType.ALL)
private List<Carz> cars;
...........................
}
@Embeddable
public class LotzPK implements Serializable
{
@Column(name="id", nullable=false)
private Integer id;
@Column(name="loc_code", nullable=false)
private String locCode;
...........................
}
In this case I need a one-to-many relationship on Carz.id = Lotz.locCode. However, there doesn't appear to be a way to do this.
When this is deployed, this exception occurs:
org.hibernate.AnnotationException: Column name id of hqb.model.Lotz not found in JoinColumns.referencedColumnName
at org.hibernate.cfg.annotations.TableBinder.bindFk(TableBinder.java:306)
at org.hibernate.cfg.FkSecondPass.doSecondPass(FkSecondPass.java:64)
at org.hibernate.cfg.AnnotationConfiguration.processFkSecondPassInOrder(AnnotationConfiguration.java:433)
at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:287)
at org.hibernate.cfg.Configuration.buildMappings(Configuration.java:1115)
at org.hibernate.ejb.Ejb3Configuration.buildMappings(Ejb3Configuration.java:1211)
at org.hibernate.ejb.EventListenerConfigurator.configure(EventListenerConfigurator.java:154)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:847)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:385)
at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:126)
at org.jboss.ejb3.entity.PersistenceUnitDeployment.start(PersistenceUnitDeployment.java:264)
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.jboss.ejb3.ServiceDelegateWrapper.startService(ServiceDelegateWrapper.java:102)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
at sun.reflect.GeneratedMethodAccessor263.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
...........................
I can deploy the app if I map both fields in the Lotz PK class like so:
@Entity
@Table(name="car")
public class Carz implements Serializable
{
@Id
private Integer id;
...........................
@ManyToOne(fetch=FetchType.LAZY)
@JoinColumns
({
@JoinColumn(name="loc_code", referencedColumnName="loc_code", insertable=false, updatable=false),
@JoinColumn(name="", referencedColumnName="id", insertable=false, updatable=false) //INCORRECTLY DEFINED RELATIONSHIP!
})
private Lotz lot;
...........................
}
But obviously this is no good, it generates bad SQL at runtime:
/* select
c
from
Carz c
left join
fetch c.lot */ select
carz0_.id as id198_0_,
lotz1_.id as id199_1_,
lotz1_.loc_code as loc2_199_1_,
carz0_.make as make198_0_,
carz0_.model as model198_0_,
carz0_.manufactured as manufact4_198_0_,
carz0_.lot_id as lot5_198_0_,
carz0_.loc_code as loc6_198_0_, --no such column...
lotz1_.name as name199_1_,
lotz1_.location as location199_1_
from
car carz0_
left outer join
lot lotz1_
on carz0_.lot_id=lotz1_.id --oops! Hibernate defaulted a relationship here...
and carz0_.loc_code=lotz1_.loc_code
In reality, this is the SQL I'm trying to achieve, by repairing the above query manually:
select
carz0_.id as id198_0_,
lotz1_.id as id199_1_,
lotz1_.loc_code as loc2_199_1_,
carz0_.make as make198_0_,
carz0_.model as model198_0_,
carz0_.manufactured as manufact4_198_0_,
carz0_.loc_code as loc6_198_0_,
lotz1_.name as name199_1_,
lotz1_.location as location199_1_
from
car carz0_
left outer join
lot lotz1_
on carz0_.loc_code=lotz1_.loc_code
This is consistent w/ the EJB 3.0 spec (and Glassfish+Toplink) but that's only because the spec doesn't define exacltly how to handle this. However, that being said, this seems important enough for Hibernate to be able to manage?
--
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, 9 months
[Hibernate-JIRA] Created: (HHH-4446) NonUniqueObjectException and lost inserts
by darko ostricki (JIRA)
NonUniqueObjectException and lost inserts
-----------------------------------------
Key: HHH-4446
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4446
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.1, 3.2.6
Environment: occured in hibernate 3.3.1GA an 3.2.6GA on tomcat 5.5. with JNDI datasource configuration on HSQL DB 1.8.0.9 & SQL Server 2005
Reporter: darko ostricki
Attachments: hibernate.7z
used tables with native (identity) generator on both hsql and MSSQL 2005 Database.
Error occures randomly on Hibernate 3.3.1GA & 3.2.6GA therefore it's difficult to debug
I am experiencing a problem when persisting a large amount of Serialized objects within a single Transaction. (But not all objects of same type/mapping - primary Id's are null)
Sometimes the savOrUpdate doesn't actually perform an insert (skips an insert) - but assigns the bean in the persistence context the wrong generated Id.
The assigned generated id is actually genereted by an insert that should have been executed later in the batch.
The Insert that followed and got the correctly generated id, is inserted correctly to the database according to the transaction logs.
But the check of uniqueness fails because the bean in the persistencecontext which has NOT bean inserted properly (according to the transaction logs of the database and !!without!! errormessage) has the given id already assigned (in session context).
Maybe an example will make more clear what happens.
4 objects A,B,C,D will get persisted with saveOrUpdate the generated ids should be 0,1,2,3
Iteration 1 (OK) :
A -> saveOrUpdate -> Insert A into xyz (persist in Db) -> DB has Transact logs -> call identity delivers ID 0 -> bean in sessioncontext has id 0
Iteration 2 (something wents wrong) :
B -> saveOrUpdate -> Insert B into xyz (persist in Db) -> DB has NO Transact logs -> somehow bean gets id 2
Iteration 3 (OK) :
C -> saveOrUpdate -> Insert C into xyz (persist in Db) -> DB has Transact logs -> call identity delivers ID 1 because previous insert went wriong without error
-> bean in sessioncontext has id 1
Iteration 4 (Error happens) :
D -> saveOrUpdate -> Insert D into xyz (persist in Db) -> DB has Transact logs -> call identity delivers ID 2 -> bean in sessioncontext has id 2
-> checkOfuniqueness throws exception because a bean with the id is already in the session.
A,C,D are persisted accorifing to transaction logs of DB
org.hibernate.NonUniqueObjectException: a different object with the same identifier value was already associated with the session: [de.tts.bd.model.HistoryEntry#4223]
at org.hibernate.engine.StatefulPersistenceContext.checkUniqueness(StatefulPersistenceContext.java:613)
at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:326)
at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:204)
at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:130)
at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.saveWithGeneratedOrRequestedId(DefaultSaveOrUpdateEventListener.java:210)
at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.entityIsTransient(DefaultSaveOrUpdateEventListener.java:195)
at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.performSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:117)
at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:93)
at org.hibernate.impl.SessionImpl.fireSaveOrUpdate(SessionImpl.java:534)
at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java:526)
at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java:522)
at de.tts.bd.business.exchange.serialize.ImportSerializable.persistEntity(ImportSerializable.java:260)
The error occures randomly on different mappings and was not reproducable with load tests of single Objecttypes @see the attachment zip file. But the attachment should show the environmental context how it happens.
--
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, 9 months