[Hibernate-JIRA] Created: (HHH-5221) Support orphanRemoval on @OneToOne in @Embedded
by Anders Wallgren (JIRA)
Support orphanRemoval on @OneToOne in @Embedded
-----------------------------------------------
Key: HHH-5221
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5221
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.5.1, 3.5.0-Final
Reporter: Anders Wallgren
Comment from {{Cascade.cascadeProperty}}:
{code}
// association defined on component
// todo : this is currently unsupported because of the fact that
// we do not know the loaded state of this value properly
// and doing so would be very difficult given how components and
// entities are loaded (and how 'loaded state' is put into the
// EntityEntry). Solutions here are to either:
// 1) properly account for components as a 2-phase load construct
// 2) just assume the association was just now orphaned and
// issue the orphan delete. This would require a special
// set of SQL statements though since we do not know the
// orphaned value, something a delete with a subquery to
// match the owner.
{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, 7 months
[Hibernate-JIRA] Commented: (HHH-1480) JOIN precendence rules per SQL-99
by Mark Derricutt (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1480?page=c... ]
Mark Derricutt commented on HHH-1480:
-------------------------------------
Under PostgreSQL this change causes many problems for us. We were tracking the milestone releases and found that between M1 and M2+ a lot of queries blowing out the server and running for 14+ days before they were noticed.
Has anyone on the Hibernate team seem this under PostgreSQL ( 8.3/8.4 ) - we're using the org.hibernate.dialect.PostgreSQLDialect dialect.
> JOIN precendence rules per SQL-99
> ---------------------------------
>
> Key: HHH-1480
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1480
> Project: Hibernate Core
> Issue Type: New Feature
> Components: query-hql
> Affects Versions: 3.1.2
> Reporter: trebor iksrazal
> Assignee: Steve Ebersole
> Fix For: 3.5.0-Beta-2
>
>
> In SQL-92 joins performed in the where clause (comma operator in from clause) and joins performed in the from clause (join keyword) had the same precedence. SQL-99 clarified this such that the from clause joins had higher precedence.
> Hibernate currently treats these as having the same precedence.
> A good explanation comes from the MySQL docs ( http://dev.mysql.com/doc/refman/5.0/en/join.html ) :
> #
> Previously, the comma operator (,) and JOIN both had the same precedence, so the join expression t1, t2 JOIN t3 was interpreted as ((t1, t2) JOIN t3). Now JOIN has higher precedence, so the expression is interpreted as (t1, (t2 JOIN t3)). This change affects statements that use an ON clause, because that clause can refer only to columns in the operands of the join, and the change in precedence changes interpretation of what those operands are.
> Example:
> CREATE TABLE t1 (i1 INT, j1 INT);
> CREATE TABLE t2 (i2 INT, j2 INT);
> CREATE TABLE t3 (i3 INT, j3 INT);
> INSERT INTO t1 VALUES(1,1);
> INSERT INTO t2 VALUES(1,1);
> INSERT INTO t3 VALUES(1,1);
> SELECT * FROM t1, t2 JOIN t3 ON (t1.i1 = t3.i3);
> Previously, the SELECT was legal due to the implicit grouping of t1,t2 as (t1,t2). Now the JOIN takes precedence, so the operands for the ON clause are t2 and t3. Because t1.i1 is not a column in either of the operands, the result is an Unknown column 't1.i1' in 'on clause' error. To allow the join to be processed, group the first two tables explicitly with parentheses so that the operands for the ON clause are (t1,t2) and t3:
> SELECT * FROM (t1, t2) JOIN t3 ON (t1.i1 = t3.i3);
> Alternatively, avoid the use of the comma operator and use JOIN instead:
> SELECT * FROM t1 JOIN t2 JOIN t3 ON (t1.i1 = t3.i3);
> This change also applies to statements that mix the comma operator with INNER JOIN, CROSS JOIN, LEFT JOIN, and RIGHT JOIN, all of which now have higher precedence than the comma operator.
--
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, 7 months
[Hibernate-JIRA] Created: (ANN-846) Infinite loop occurs while doing findById on a Parent domain Object having OneToMany relationship with child domain with composite primary key
by RAMESH BABU NL (JIRA)
Infinite loop occurs while doing findById on a Parent domain Object having OneToMany relationship with child domain with composite primary key
----------------------------------------------------------------------------------------------------------------------------------------------
Key: ANN-846
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-846
Project: Hibernate Annotations
Issue Type: Improvement
Affects Versions: 3.4.0.GA
Environment: Hibernate Annotations 3.4.0.GA, HSqlDB and Oracle
Reporter: RAMESH BABU NL
Attachments: Organization.java, OrganizationApplications.java, OrganizationApplicationsPK.java
We are using Hibernate annotations version 3.4.0.G.A
We are establishing a OneToMany relationship using the annotation @OnetoMany for a Parent and Child domain objects
where the child domain has a composite primary key.
We have two domain objects
Organization [Parent]
OrganizationApplications [Child]
We want to have a OnetoMany relationship between Organization and OrganizationApplications.
As shown below OrganizationApplications contains a composite primary key, of two columns(Organization Id, ApplicationId[foreignkey from other table called APPLICATIONS])
Organizations.java
-------------------
@OneToMany(targetEntity=gov.osc.enrollment.backend.domain.OrganizationApplications.class, cascade=CascadeType.ALL, fetch = FetchType.EAGER,
mappedBy="id.organization")
private Set<OrganizationApplications> organizationApps = new HashSet<OrganizationApplications>();
OrganizationApplications.java
---------------------------------------------------------------------
public class OrganizationApplications extends EnvelopeInfo implements Serializable {
private static final long serialVersionUID = 1L;
@EmbeddedId
private OrganizationApplicationsPK id;
public OrganizationApplicationsPK getId() {
return id;
}
public void setId(OrganizationApplicationsPK id) {
this.id = id;
}
OrganizationApplicationsPK.java
---------------------------------------------------------------------
@Embeddable
public class OrganizationApplicationsPK implements Serializable {
private static final Long serialVersionUID = 1L;
public OrganizationApplicationsPK() {
super();
}
@ManyToOne
@JoinColumn(name="APPLICATION_ID",nullable=false)
private Applications application;
@ManyToOne(targetEntity=gov.osc.enrollment.backend.domain.Organization.class, cascade=CascadeType.ALL)
@JoinColumn(name="ORGANIZATION_ID", referencedColumnName="ORGANIZATION_ID", nullable=false, insertable=true, updatable=true)
private Organization organization;
public Applications getApplication() {
return application;
}
public void setApplication(Applications application) {
this.application = application;
}
public Organization getOrganization() {
return organization;
}
public void setOrganization(Organization organization) {
this.organization = organization;
}
@Override
public boolean equals(Object o) {
if (o == this) {
return true;
}
if ( ! (o instanceof OrganizationApplicationsPK)) {
return false;
}
OrganizationApplicationsPK other = (OrganizationApplicationsPK) o;
return (this.getOrganization().getId() == other.getOrganization().getId())
&& (this.getApplication().getId() == other.getApplication().getId());
}
@Override
public int hashCode() {
final int prime = 31;
int hash = 17;
hash = hash * prime + ((int) (this.getOrganization().getId() ^ (this.getOrganization().getId() >>> 32)));
hash = hash * prime + ((int) (this.getApplication().getId() ^ (this.getApplication().getId() >>> 32)));
return hash;
}
}
Please see the attached java files for complete code and also the exception stack trace.
Questions:
1. When we do a findById query on Organization table the system goes into infinite loop and never gets out .
How ever we are able to insert a record in Organization and its child OrganizationApplications.
2. In the Organization.java domain, if you notice we are using mappedby="id.organization". Is this a valid mapping ?
If not why does this parameter work for insert and not for a entityManager.findById, doing so leads to infinite loop.
--
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, 7 months
[Hibernate-JIRA] Updated: (HHH-1907) offload metadata information from ComponentType to SessionFactory
by Steve Ebersole (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1907?page=c... ]
Steve Ebersole updated HHH-1907:
--------------------------------
Description:
Specifically, we need to move all the code directly dealing with property-access, instantiation, etc out of here. So where do we move it? Well, EntityType for example moves this stuff off to the persisters; the type then just looks up the persister when needed. Not sure we actually need a persister per-se for handling components; perhaps just ComponentMetamodel is enough...
Why is this important? Well the way ComponentType is currently structured leads to the need for certain configuration properties to be classloader scoped (static on Environment) instead of SessionFactory scoped. This is painful for two in particular: 1) whether to use reflection optimization and 2) bytecode provider.
Also, this change should allow us to cleanup how property accessors are built
Long term it would facilitate the ability to have hierarchies of components as well as loading components in a 2-phase-load paradigm like entities and collections.
was:
Specifically, we need to move all the code directly dealing with property-access, instantiation, etc out of here. So where do we move it? Well, EntityType for example moves this stuff off to the persisters; the type then just looks up the persister when needed. Not sure we actually need a persister per-se for handling components; perhaps just ComponentMetamodel is enough...
Why is this important? Well the way ComponentType is currently structured leads to the need for certain configuration properties to be classloader scoped (static on Environment) instead of SessionFactory scoped. This is painful for two in particular: 1) whether to use reflection optimization and 2) bytecode provider.
Also, this change should allow us to cleanup how property accessors are built
> offload metadata information from ComponentType to SessionFactory
> -----------------------------------------------------------------
>
> Key: HHH-1907
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1907
> Project: Hibernate Core
> Issue Type: Improvement
> Components: core
> Reporter: Steve Ebersole
> Assignee: Steve Ebersole
> Fix For: cfg-rework
>
>
> Specifically, we need to move all the code directly dealing with property-access, instantiation, etc out of here. So where do we move it? Well, EntityType for example moves this stuff off to the persisters; the type then just looks up the persister when needed. Not sure we actually need a persister per-se for handling components; perhaps just ComponentMetamodel is enough...
> Why is this important? Well the way ComponentType is currently structured leads to the need for certain configuration properties to be classloader scoped (static on Environment) instead of SessionFactory scoped. This is painful for two in particular: 1) whether to use reflection optimization and 2) bytecode provider.
> Also, this change should allow us to cleanup how property accessors are built
> Long term it would facilitate the ability to have hierarchies of components as well as loading components in a 2-phase-load paradigm like entities and collections.
--
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, 7 months
[Hibernate-JIRA] Created: (HHH-5135) Prefix is missed in HQL query for property mapped to column 'TO_DATE' on Oracle 10g
by Vladimir Ivanov (JIRA)
Prefix is missed in HQL query for property mapped to column 'TO_DATE' on Oracle 10g
-----------------------------------------------------------------------------------
Key: HHH-5135
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5135
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.5.1, 3.5.0-Final
Environment: Hibernate 3.5.1, Oracle 10.2.0.1.0
Reporter: Vladimir Ivanov
Attachments: test_case.zip
I have entity 'Period' with property 'toDate' mapped to database column with name 'TO_DATE' (Our database is Oracle 10g). When this entity is queried via HQL, prefix for this entity is missed. Following SQL query is produced:
Hibernate:
/*
from
Period p */ select
*
from
( select
period0_.ID as ID44_,
period0_.TXN_VER as TXN3_44_,
period0_.FROM_DATE as FROM4_44_,
TO_DATE as TO5_44_,
period0_.POSITION_MONTH as POSITION7_44_,
period0_.IS_CLOSE as IS12_44_,
period0_.IS_OPEN as IS13_44_,
period0_.DISC_TYPE as DISC2_44_
from
SOME_SCHEMA.T_PERIOD period0_ )
where
rownum <= ?
This leads to database error in case of more advanced query (with joins etc). For example, we have following error in production: java.sql.SQLException: ORA-00918: column ambiguously defined
Probably the reason of this behaviour is that Hibernate tries to interpret 'TO_DATE' as the name of SQL function.
In Hibernate 3.3.2.GA prefix is added correctly.
Domain object, DAO, Test and Hibernate configuration are in the attachment.
I used Spring framework to configure test.
--
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, 7 months
[Hibernate-JIRA] Created: (HHH-5063) Projections that have aliases same as the property name result in invalid sql
by Shawn Clowater (JIRA)
Projections that have aliases same as the property name result in invalid sql
-----------------------------------------------------------------------------
Key: HHH-5063
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5063
Project: Hibernate Core
Issue Type: Bug
Components: query-criteria
Affects Versions: 3.5.0-Final
Reporter: Shawn Clowater
I have a criteria query that is using an AliasToBeanTransformer that I'm using to selectively populate some of the properties. It appears that the transformer requires the alias values to match the properties of your bean so that it can call the setters via reflection.
The code snippet is similar to the following
return (List<DataProvider>) session.createCriteria(DataProvider.class)
.setProjection(Projections.projectionList()
.add(Projections.property("dataProviderId), "dataProviderId")
.add(Projections.property("uuid"), "uuid")
.add(Projections.property("name"), "name")
.add(Projections.property("dataProviderGroup"), "dataProviderGroup")
.add(Projections.property("verifiedFlg"), "verifiedFlg")
)
.setResultTransformer(new AliasToBeanResultTransformer(DataProvider.class))
.addOrder(Order.asc("name"))
.list();
And is resulting in the following SQL
select y0_ as y0_, y1_ as y1_, y2_ as y2_, y3_ as y3_, y4_ as y4_ from DATA_PROVIDER this_ order by y2_ asc
I can assure you that my column names are not y0_, etc.
This worked in 3.3.2 and I am suspecting it might be due to the change for HHH-1088. If I don't specify the alias or even change the value then it will produce a valid query it just won't populate by bean correctly.
i.e. if I append anything to the end of the first alias (i.e. "hi") results in:
select this_.DATA_PROVIDER_ID as y0_, y1_ as y1_, y2_ as y2_, y3_ as y3_, y4_ as y4_ from DATA_PROVIDER this_ order by y2_ asc
--
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, 7 months
[Hibernate-JIRA] Created: (HHH-5219) DATETIME column incorrectly validates against DATE column
by Ian Haken (JIRA)
DATETIME column incorrectly validates against DATE column
---------------------------------------------------------
Key: HHH-5219
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5219
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 3.5.1
Reporter: Ian Haken
Attachments: validation-fix.patch
org.hibernate.mapping.Table.validateColumns incorrectly validates if the expected SqlType is DATETIME and the actual SqlType is DATE. This can be reproduced as follows:
Create a MySQL table with DATE type for column foo.
Create an Entity with java.util.Date member foo, annotated with @Temporal(TemporalType.TIMESTAMP).
Initiate a Hibernate session with hibernate.hbm2ddl.auto=validate.
An exception should be thrown and is not. Looking at the code in src/main/java/org/hibernate/mapping/Table.java, it is clear why this would occur; the check is:
col.getSqlType( dialect, mapping ).toLowerCase().startsWith( columnInfo.getTypeName().toLowerCase() )
I'm not sure if there was a particular reason for using startsWith rather than equals, but I've changed startsWith to equals in the suggested patch (attached).
--
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, 7 months
[Hibernate-JIRA] Created: (HSEARCH-526) Mass Indexer Logs Multiple NullPointerExceptions
by j nadler (JIRA)
Mass Indexer Logs Multiple NullPointerExceptions
------------------------------------------------
Key: HSEARCH-526
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-526
Project: Hibernate Search
Issue Type: Bug
Affects Versions: 3.2.0.Final
Environment: Hibernate Core 3.5.1, Hibernate Search 3.2.0.Final
Reporter: j nadler
We just moved our 'old style' reindex code to the new MassIndexer and gave it a run. It seems to have mostly worked (the index was clearly populated with some records) but a few NPEs in the logs:
[2010-05-06 08:22:25.115,105054]ERROR[Hibernate Search: collectionsloader-4](EntityConsumerLuceneworkProducer.java:96) - error during batch indexing:
java.lang.NullPointerException
at org.hibernate.search.batchindexing.EntityConsumerLuceneworkProducer.index(EntityConsumerLuceneworkProducer.java:139)
at org.hibernate.search.batchindexing.EntityConsumerLuceneworkProducer.indexAllQueue(EntityConsumerLuceneworkProducer.java:117)
at org.hibernate.search.batchindexing.EntityConsumerLuceneworkProducer.run(EntityConsumerLuceneworkProducer.java:92)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
[2010-05-06 08:22:37.170,117109]ERROR[Hibernate Search: collectionsloader-1](EntityConsumerLuceneworkProducer.java:96) - error during batch indexing:
java.lang.NullPointerException
at org.hibernate.search.batchindexing.EntityConsumerLuceneworkProducer.index(EntityConsumerLuceneworkProducer.java:139)
at org.hibernate.search.batchindexing.EntityConsumerLuceneworkProducer.indexAllQueue(EntityConsumerLuceneworkProducer.java:117)
at org.hibernate.search.batchindexing.EntityConsumerLuceneworkProducer.run(EntityConsumerLuceneworkProducer.java:92)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
[2010-05-06 08:22:37.466,117405]ERROR[Hibernate Search: collectionsloader-2](EntityConsumerLuceneworkProducer.java:96) - error during batch indexing:
java.lang.NullPointerException
at org.hibernate.search.batchindexing.EntityConsumerLuceneworkProducer.index(EntityConsumerLuceneworkProducer.java:139)
at org.hibernate.search.batchindexing.EntityConsumerLuceneworkProducer.indexAllQueue(EntityConsumerLuceneworkProducer.java:117)
at org.hibernate.search.batchindexing.EntityConsumerLuceneworkProducer.run(EntityConsumerLuceneworkProducer.java:92)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
[2010-05-06 08:22:37.566,117505]ERROR[Hibernate Search: collectionsloader-8](EntityConsumerLuceneworkProducer.java:96) - error during batch indexing:
java.lang.NullPointerException
at org.hibernate.search.batchindexing.EntityConsumerLuceneworkProducer.index(EntityConsumerLuceneworkProducer.java:139)
at org.hibernate.search.batchindexing.EntityConsumerLuceneworkProducer.indexAllQueue(EntityConsumerLuceneworkProducer.java:117)
at org.hibernate.search.batchindexing.EntityConsumerLuceneworkProducer.run(EntityConsumerLuceneworkProducer.java:92)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
[2010-05-06 08:22:51.710,131649]WARN [http-8080-7](StatefulPersistenceContext.java:662) - Narrowing proxy to class com.attensa.core.entity.User - this operation breaks ==
[2010-05-06 08:22:51.738,131677]DEBUG[http-8080-7](BaseArticleListQuery.java:579) - getLatestDateModified: took: 0:00:00.024
--
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, 7 months