[Hibernate-JIRA] Created: (HHH-3045) Duplicated column aliases in scalar query
by Anderson Souza (JIRA)
Duplicated column aliases in scalar query
-----------------------------------------
Key: HHH-3045
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3045
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.5
Environment: Hibernate 3.2.4SP1, 3.2.5GA
Oracle 10g
Reporter: Anderson Souza
Priority: Critical
Attachments: ddl-tables.sql, dominio.zip
The HQL bellow works fine, but when I add a call to a funcion in the select clause the SQL generated has duplicated aliases and it generate error on query execution, because the query is paginated.
{code}
select a
from Area a
inner join fetch a.horarioPadrao
left outer join fetch a.horarioTemporario as hrtemp
{code}
The SQL generated for this query is:
{code}
select * from (
select area0_.cod_local as cod1_15_0_,
horarioare1_.cod_area as cod1_6_1_,
horarioare2_.cod_area as cod1_7_2_,
area0_.des_local as des2_15_0_,
area0_.sig_local as sig3_15_0_,
area0_.flg_extinto as flg4_15_0_,
horarioare1_.hr_hora_ini as hr2_6_1_,
horarioare1_.hr_hora_fim as hr3_6_1_,
horarioare1_.flg_fim_semana as flg4_6_1_,
horarioare2_.hr_hora_ini as hr2_7_2_,
horarioare2_.hr_hora_fim as hr3_7_2_,
horarioare2_.flg_fim_semana as flg4_7_2_,
horarioare2_.dat_ini_vigencia as dat5_7_2_,
horarioare2_.dat_fim_vigencia as dat6_7_2_
from esq_fp.tb_local area0_
inner join tb_horario_local_padrao horarioare1_ on area0_.cod_local=horarioare1_.cod_area
left outer join tb_horario_local_temporario horarioare2_ on area0_.cod_local=horarioare2_.cod_area
where 1=1
order by area0_.sig_local )
where rownum <= ?
{code}
The scalar HQL query that generate duplicated column names is:
{code}
select a, count(*)
from Area a
inner join fetch a.horarioPadrao
left outer join fetch a.horarioTemporario as hrtemp
{code}
The SQL generated is:
{code}
select * from (
select area0_.cod_local as col_0_0_,
count(*) as col_1_0_,
horarioare1_.cod_area as cod1_6_1_,
horarioare2_.cod_area as cod1_7_2_,
area0_.cod_local as cod1_15_0_,
horarioare1_.cod_area as cod1_6_1_,
horarioare2_.cod_area as cod1_7_2_,
area0_.des_local as des2_15_0_,
area0_.sig_local as sig3_15_0_,
area0_.flg_extinto as flg4_15_0_,
horarioare1_.hr_hora_ini as hr2_6_1_,
horarioare1_.hr_hora_fim as hr3_6_1_,
horarioare1_.flg_fim_semana as flg4_6_1_,
horarioare2_.hr_hora_ini as hr2_7_2_,
horarioare2_.hr_hora_fim as hr3_7_2_,
horarioare2_.flg_fim_semana as flg4_7_2_,
horarioare2_.dat_ini_vigencia as dat5_7_2_,
horarioare2_.dat_fim_vigencia as dat6_7_2_
from esq_fp.tb_local area0_
inner join tb_horario_local_padrao horarioare1_ on area0_.cod_local=horarioare1_.cod_area
left outer join tb_horario_local_temporario horarioare2_ on area0_.cod_local=horarioare2_.cod_area
where 1=1
order by area0_.sig_local )
where rownum <= ?
{code}
As you can see the aliases cod1_6_1_ and cod1_7_2_ are repeated and this repetition breaks the paginated query, beacause the main query appears in the from clause.
The HBM's and classes are 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, 4 months
[Hibernate-JIRA] Created: (HHH-3058) When using native sql query and multiple selects with setMaxResults, Hibernate inserts the TOP statement in the first query
by Sean Blaes (JIRA)
When using native sql query and multiple selects with setMaxResults, Hibernate inserts the TOP statement in the first query
---------------------------------------------------------------------------------------------------------------------------
Key: HHH-3058
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3058
Project: Hibernate3
Issue Type: Bug
Components: query-sql
Affects Versions: 3.2.4.sp1
Environment: Hibernate 3.2.4sp1, Microsoft SQL Server
Reporter: Sean Blaes
Priority: Minor
When using a query similar to the following:
DECLARE @SUB_TABLE TABLE(
ID INT
)
INSERT INTO @SUB_TABLE
SELECT ID
FROM FOO
SELECT *
FROM BAR
INNER JOIN @SUB_TABLE
ON ...
Then if I call setMaxResults(100) on the query object. It inserts "TOP 100" in the first query, which isn't really what would be expected. Since the second SELECT actually consists of the data that will be returned, the TOP 100 statement should go there.
I'd expect it's an easy fix. Just start your search for SELECT from the bottom rather than the top. However, I guess you have to make sure you're not hitting a subquery of a larger select either... I may try cooking up a patch this weekend for this if I can find the time, and I'll attach it to this issue if I do.
--
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, 4 months
[Hibernate-JIRA] Created: (HHH-1989) Deleted object remains referenced in 2nd level cache collections
by Justin Haddad (JIRA)
Deleted object remains referenced in 2nd level cache collections
----------------------------------------------------------------
Key: HHH-1989
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1989
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.0.cr2
Environment: Spring 1.2.8, Hibernate 3.2, Postgres 8.0.3
Reporter: Justin Haddad
This problem seems identical to issue NH-678. I have enabled caching for an one-to-many association. I use Ehcache. I have a test in which I load the parent object along with its collection. Both the parent and the collection wind up in the 2nd level cache. I then delete an object that is in the collection, not by removing it from the collection, but rather by doing a delete on the object itself. After deleting, I try to reload the parent and get the following exception (User#3102 is the deleted object):
aused by: org.hibernate.ObjectNotFoundException: No row with the given identifier exists: [com.bluenotenetworks.common.management.sm.User#3102]
at org.hibernate.impl.SessionFactoryImpl$1.handleEntityNotFound(SessionFactoryImpl.java:372)
at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:128)
at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:178)
at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:86)
at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:871)
at org.hibernate.impl.SessionImpl.internalLoad(SessionImpl.java:839)
at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:266)
at org.hibernate.type.ManyToOneType.assemble(ManyToOneType.java:177)
at org.hibernate.collection.PersistentSet.initializeFromCache(PersistentSet.java:101)
at org.hibernate.cache.entry.CollectionCacheEntry.assemble(CollectionCacheEntry.java:35)
at org.hibernate.event.def.DefaultInitializeCollectionEventListener.initializeCollectionFromCache(DefaultInitializeCollectionEventListener.java:130)
at org.hibernate.event.def.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:48)
at org.hibernate.impl.SessionImpl.initializeCollection(SessionImpl.java:1705)
(continues on)
I stepped through the code in the debugger and can see that the object's ID (3102 in this case) remains in the cached collection even after the deletion.
--
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, 4 months
[Hibernate-JIRA] Created: (HHH-3075) Should be possible to register UserTypes for known property types (classes) in configuration
by Martin Probst (JIRA)
Should be possible to register UserTypes for known property types (classes) in configuration
--------------------------------------------------------------------------------------------
Key: HHH-3075
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3075
Project: Hibernate3
Issue Type: Improvement
Components: core
Environment: n/a
Reporter: Martin Probst
Priority: Minor
Currently, when persisting primitive properties of a class that are not known to Hibernate, there are only cumbersome ways to tell Hibernate that a certain UserType should be used. Good example is Joda Time:
<pre>
@Entity
class MyClass {
org.joda.time.DateTime foo;
}
</pre>
.. which will result in ugly binary fields in database. Next try:
<pre>
@Entity
class MyClass {
@Type(type = "org.joda.time.contrib.hibernate.PersistentDateTime")
org.joda.time.DateTime foo;
}
</pre>
That works, but now I have to specify that on all time fields of all classes. Plus it's different types for different classes, which makes it more messy. And it's simply a string in code, so it's fragile to refactoring, code move, etc. TypeDefs allow a shorter handle for certain types, but don't really address the refactoring issues.
A better way might be to allow configurations to register UserTypes for known classes. E.g. have a configuration directive like this:
<mappable-type class="org.joda.time.DateTime" usertype="org.joda.time.hibernate.DateTimeType"/>
This would allow the classes to stay clean from type mappings and reduce coupling between domain objects and persistence mapping.
This might be as easy as allowing the org.hibernate.type.TypeFactory map to be extended at configuration time.
--
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, 4 months
[Hibernate-JIRA] Created: (HHH-5004) Specifying entity access type at class level and then redundantly again on id field or getId() causes EntityManagerFactory configuration failure
by Jesse Hutton (JIRA)
Specifying entity access type at class level and then redundantly again on id field or getId() causes EntityManagerFactory configuration failure
------------------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-5004
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5004
Project: Hibernate Core
Issue Type: Bug
Components: annotations, entity-manager
Affects Versions: 3.5.0-CR-2
Environment: I'm developing on Fedora 12 64bit version. java version: Java(TM) SE Runtime Environment (build 1.6.0_18-b07)
Reporter: Jesse Hutton
Priority: Minor
Attachments: testHibernate.tar.gz
If you annotation an entity class with @Access and either AccessType.FIELD or AccessType.PROPERTY and then repeat the same respective access annotation for identifier of the class, hibernate will not be able to find the identifier. An example stack trace is:
javax.persistence.PersistenceException: [PersistenceUnit: testhibernate] Unable to configure EntityManagerFactory
...
Caused by: org.hibernate.AnnotationException: No identifier specified for entity: com.mycompany.testhibernate.Foo
...
To annotate a class as such is clearly redundant, but it doesn't seem like it should really cause this error. I happened to have discovered it while experimenting with different access type options in JPA 2 using EclipseLink, forgetting to remove an access type annotation to the getId() method of my entity, and then eventually switching JPA providers to Hibernate. Under EclipseLink, there was no problem with the redundant annotations.
Attached is a sample test app illustrating the problem. It has access PROPERTY specified, but the error occurs with FIELD just the same.
--
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, 4 months
[Hibernate-JIRA] Created: (HV-293) Annotation processor fails in Eclipse when evaluating custom constraints not defined in the current project
by Gunnar Morling (JIRA)
Annotation processor fails in Eclipse when evaluating custom constraints not defined in the current project
-----------------------------------------------------------------------------------------------------------
Key: HV-293
URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-293
Project: Hibernate Validator
Issue Type: Bug
Affects Versions: 4.1.0-Beta-1
Reporter: Gunnar Morling
Assignee: Hardy Ferentschik
In certain situations the AP fails when being integrated in Eclipse with the following exception:
java.lang.AssertionError: Class org.hibernate.validator.constraints.impl.LengthValidator specified in @Constraint.validatedBy doesn't implement ConstraintValidator.
at org.hibernate.validator.ap.util.ConstraintHelper.getConstraintValidatorSuperType(ConstraintHelper.java:497)
at org.hibernate.validator.ap.util.ConstraintHelper.getSupportedType(ConstraintHelper.java:426)
at org.hibernate.validator.ap.util.ConstraintHelper.getSupportedTypes(ConstraintHelper.java:402)
at org.hibernate.validator.ap.util.ConstraintHelper.checkCustomConstraint(ConstraintHelper.java:356)
at org.hibernate.validator.ap.util.ConstraintHelper.checkConstraint(ConstraintHelper.java:295)
at org.hibernate.validator.ap.ConstraintAnnotationVisitor.checkConstraintAtField(ConstraintAnnotationVisitor.java:290)
at org.hibernate.validator.ap.ConstraintAnnotationVisitor.visitVariableAsField(ConstraintAnnotationVisitor.java:174)
at org.hibernate.validator.ap.ConstraintAnnotationVisitor.visitVariableAsField(ConstraintAnnotationVisitor.java:45)
at javax.lang.model.util.ElementKindVisitor6.visitVariable(ElementKindVisitor6.java:199)
at org.eclipse.jdt.internal.compiler.apt.model.VariableElementImpl.accept(VariableElementImpl.java:55)
at org.hibernate.validator.ap.ConstraintValidationProcessor.process(ConstraintValidationProcessor.java:84)
at org.eclipse.jdt.internal.compiler.apt.dispatch.RoundDispatcher.handleProcessor(RoundDispatcher.java:139)
at org.eclipse.jdt.internal.compiler.apt.dispatch.RoundDispatcher.round(RoundDispatcher.java:121)
at org.eclipse.jdt.internal.compiler.apt.dispatch.BaseAnnotationProcessorManager.processAnnotations(BaseAnnotationProcessorManager.java:159)
at org.eclipse.jdt.internal.apt.pluggable.core.dispatch.IdeAnnotationProcessorManager.processAnnotations(IdeAnnotationProcessorManager.java:134)
at org.eclipse.jdt.internal.compiler.Compiler.processAnnotations(Compiler.java:810)
at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:428)
at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:364)
at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.compile(IncrementalImageBuilder.java:321)
at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:301)
at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.build(IncrementalImageBuilder.java:134)
at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildDeltas(JavaBuilder.java:265)
at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:193)
at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:627)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:170)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:201)
at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:253)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:256)
at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:309)
at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:341)
at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:140)
at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:238)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
This happens, if the AP examines a constraint annotation, which is not defined in the currently built project itself, but is imported from some other JAR (e.g. @Length from HV):
public class TestModel {
@Length
private String test;
}
The problem occurs, regardless whether the JAR containing the constraint is on the AP classpath or not.
The AP works as expected when running on javac.
--
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, 4 months