[Hibernate-JIRA] Created: (ANN-728) @NaturalId doesn't work with @Embeddable/@Embedded
by Kenny MacLeod (JIRA)
@NaturalId doesn't work with @Embeddable/@Embedded
--------------------------------------------------
Key: ANN-728
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-728
Project: Hibernate Annotations
Issue Type: Bug
Affects Versions: 3.3.1.GA
Reporter: Kenny MacLeod
Attachments: BugTestCase.java
If I try to annotate an @Entity's field with @NaturalId, and that field happens to be @Embedded or @Embeddable, then hibernate barfs with
org.hibernate.MappingException: Unable to find logical column name from physical name component in table BugTestCase$MyEntity
at org.hibernate.cfg.Mappings.getLogicalColumnName(Mappings.java:514)
at org.hibernate.cfg.IndexOrUniqueKeySecondPass.doSecondPass(IndexOrUniqueKeySecondPass.java:61)
at org.hibernate.cfg.Configuration.secondPassCompile(Configuration.java:1136)
at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:324)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1292)
at org.hibernate.cfg.AnnotationConfiguration.buildSessionFactory(AnnotationConfiguration.java:859)
See attached unit test as a demonstration.
Surely this is not an exotic scenario?
Tested with Hibernate Core 3.2.6-GA
--
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, 8 months
[Hibernate-JIRA] Created: (HHH-2085) org.hibernate.event.def.DefaultLoadEventListener logs exception at info level
by Don Smith (JIRA)
org.hibernate.event.def.DefaultLoadEventListener logs exception at info level
-----------------------------------------------------------------------------
Key: HHH-2085
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2085
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.0.cr2
Environment: Hibernate 3.2.0.cr2, MySQL 4.0.18
Reporter: Don Smith
Priority: Minor
Prior to schema generation, accessing a persistent object throws an exception, as expected. The org.hibernate.event.def.DefaultLoadEventListener logs the exception at the info level, which just adds noise to the application console, and prevents application exception handling (in my case it's valid if the table doesn't exist, so I just want to catch the exception and continue). This log statement should be removed, or moved to a debug or trace level, so it won't show up in normal execution.
Code, from line 94 of org.hibernate.event.def.DefaultLoadEventListener:
catch(HibernateException e) {
log.info("Error performing load command", e);
throw e;
}
--
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, 8 months
[Hibernate-JIRA] Created: (EJB-361) Query#setParameter(int position, Object value) wrong implementation
by Fabrice Daugan (JIRA)
Query#setParameter(int position, Object value) wrong implementation
-------------------------------------------------------------------
Key: EJB-361
URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-361
Project: Hibernate Entity Manager
Issue Type: Bug
Components: EntityManager
Affects Versions: 3.3.2.GA
Reporter: Fabrice Daugan
The Hibernate JPA javax.persistence.Query#setParameter(int position, Object value) implementation does not suit to the JPA specicafication.
Indeed, the actual integer passed to the operation is converted to String by Hibernate and then used to find the named parameter.
Please have a look to the folowing stack trace :
java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.IllegalArgumentException:
org.hibernate.QueryParameterException: could not locate named parameter [1]
at org.hibernate.ejb.QueryImpl.setParameter(QueryImpl.java:185)
at org.hibernate.ejb.QueryImpl.setParameter(QueryImpl.java:240)
at org.springframework.orm.jpa.JpaTemplate$9.doInJpa(JpaTemplate.java:316)
To repoduce this error :
--
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, 9 months
[Hibernate-JIRA] Created: (HV-135) Constraints can contains constraint annotations to validate params before initialize is called
by Emmanuel Bernard (JIRA)
Constraints can contains constraint annotations to validate params before initialize is called
----------------------------------------------------------------------------------------------
Key: HV-135
URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-135
Project: Hibernate Validator
Issue Type: New Feature
Components: engine
Reporter: Emmanuel Bernard
not high priority
>From Sebastian Thomschke
--------------------------------------
I just had a look through the Hibernate Validator code, what struck me
was the way how you validate parameters. E.g.
private void validateParameters() {
if ( min < 0 ) {
throw new ValidationException( "The min parameter cannot be
negative." );
}
if ( max < 0 ) {
throw new ValidationException( "The max paramter cannot be
negative." );
}
if ( max < min ) {
throw new ValidationException( "The length cannot be
negative." );
}
}
I just had the idea, why don't we use the constraint annotations for the
built-in constraints themselves? E.g.
/**
* @return size the element must be higher or equal to
*/
@Min(0)
int min() default 0;
/**
* @return size the element must be lower or equal to
*/
@Min(0)
int max() default Integer.MAX_VALUE;
Then this kind of parameter validation could be done by the framework
and must not be repeated in every validator implementation.
What do you think?
Regards,
Seb
--------------------------------------
Emmanuel
Your idea is interesting. It could lead to infinite recursion if someone does not pay attention but could work.
I think it would better be a product feature though instead of a spec feature for this rev at least. We can't have "class" level constraints though as it conflicts with the composition model.
WDYT?
it seems to me that the ValidationException is wrong in the example you gave.
http://opensource.atlassian.com/projects/hibernate/browse/HV-134
--
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, 9 months
[Hibernate-JIRA] Created: (HHH-2548) when "order by" a composit object, which may be null, the result list returns only when the composit objcts not null
by Yu Deng (JIRA)
when "order by" a composit object, which may be null, the result list returns only when the composit objcts not null
--------------------------------------------------------------------------------------------------------------------
Key: HHH-2548
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2548
Project: Hibernate3
Issue Type: Bug
Affects Versions: 3.2.3
Environment: tomcat 5.5, eclipse3.2, jre1.5, postgreSQL8.1, hibernate3 and hibernate3.2
Reporter: Yu Deng
Priority: Critical
<hibernate-mapping package="com.grapevinecs.ams.domain.perbranch.inv">
<class name="InvItem">
<id name="id" column="id">
<generator class="hilo"/>
</id>
...
<many-to-one name="transferredDetails"/> <!-- FK: Points to corresponding entry for transferred inventory items -->
....
</class>
(another mapping file)
</hibernate-mapping>>
<hibernate-mapping package="com.grapevinecs.ams.domain.perbranch.inv">
<class name="InvTransferDetails" >
<id name="id" column="id">
<generator class="hilo"/>
</id>
<property name="returnedToICBC" type="com.grapevinecs.ams.dao.BooleanInteger" not-null="true"/>
...
</class>
</hibernate-mapping>
Probelm:
1) The result returns 3000 records ---- select count(*) from InvItem c where upper(c.invType) LIKE '%D%' and c.invSeries.closed = '0' and c.branch =60551 order by c.transferredDetails.returnedToICBC asc, c.stamp asc,c.invNmbr asc
2) result List return size 0 by this query --- from InvItem c where upper(c.invType) LIKE '%D%' and c.invSeries.closed = '0' and c.branch =60551 order by c.transferredDetails.returnedToICBC asc, c.stamp asc,c.invNmbr asc
1) is correct but 2) is not correct. only when transferredDetails in InvItem not null be returned. in case 2), I have no transferredDetails not null.
after I excuted the query 2), even I remove "c.transferredDetails.returnedToICBC asc", the result is still return nothing.
--
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, 9 months