[Hibernate-JIRA] Commented: (HHH-1134) subclass tag with discriminator in one to many mapping
by Thorsten Hilker (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1134?page=c... ]
Thorsten Hilker commented on HHH-1134:
--------------------------------------
I just realized that you switched "force" to true, too.
But I'm using Version 3.2.5.ga.
Maybe "force" is working in Version 3.2.5.ga and not in Version 3.0.5
regards
Thorsten
> subclass tag with discriminator in one to many mapping
> ------------------------------------------------------
>
> Key: HHH-1134
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1134
> Project: Hibernate3
> Issue Type: Bug
> Components: core
> Environment: hibernate 3.0.5, Oracle
> Reporter: Dilip Ranjith
>
> Consider the following hbm.xml file
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE hibernate-mapping PUBLIC
> "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
> "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
> <hibernate-mapping
> >
> <class
> name="DCDTO"
> table="ACCDC"
> dynamic-update="true"
> >
> <id
> name="ID"
> type="java.lang.String"
> >
> <column
> name="DCINFOID"
> />
> <generator class="sequence">
> <param name="sequence">DSEQ</param>
> <!--
> To add non XDoclet generator parameters, create a file named
> hibernate-generator-params-DebtorCreditorDTO.xml
> containing the additional parameters and place it in your merge dir.
> -->
> </generator>
> </id>
> <discriminator
> column="accountType"
> not-null="true"
> type="java.lang.String"
> force="true"
> insert="true"
> />
> <property
> name="creditMax"
> type="java.lang.Double"
> update="true"
> insert="true"
> column="creditMax"
> />
> <subclass
> name="CDTO"
> dynamic-update="true"
> dynamic-insert="true"
> discriminator-value="C"
> >
> </.subclass>
> <subclass
> name="DDTO"
> dynamic-update="true"
> dynamic-insert="true"
> discriminator-value="D"
> >
> </.subclass>
> </class>
> </hibernate-mapping>
> DCDTO is the super class while DDTO and CDTO are its child classes
> If in a mapped object say TDTO there are a set of CDTOs and a separate set of DDTOs
> when we get TDTO the where clause "where accountType='D' " is not there when the query for set of DDTOs are generated. so instead of a set of DDTOs i am getting a set of both DDTO's and CDTO's
--
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
16 years
[Hibernate-JIRA] Commented: (HHH-1851) relax special handling of 'id' property
by Anthony Patricio (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1851?page=c... ]
Anthony Patricio commented on HHH-1851:
---------------------------------------
tested with 3.2.4 sp1
> relax special handling of 'id' property
> ---------------------------------------
>
> Key: HHH-1851
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1851
> Project: Hibernate3
> Issue Type: Improvement
> Components: query-hql
> Environment: independent, all versions all databases.
> Reporter: Gunther Schadow
> Assignee: Steve Ebersole
> Fix For: 3.2.2
>
> Attachments: IdClassAndAnotherPropertyNamedId.zip
>
>
> Hibernate has long treated 'id' in a special manner in HQL and Criteria queries. The drawback to this has always been that it effectively means users cannot define non-identifier properties named id and refer to those properties in HQL/Criteria queries.
> Thus, I will change this such that:
> (1) 'id' can still be used to refer to the identifier property, whatever the property's actual name, as long as the entity does not define a non-identitifer property named id.
> (2) if the entity defines a non-identifier property named 'id', using 'id' in HQL or Criteria queries will refer to this non-identifier property; users would need to refer to the identifier property by its actual name.
> FYI, the original reason for this feature was to support entity's which did not define an identifier property at all (users were responsible for managing the ids seperately. That feature was never really recommended and has been deprecated since early in the 3.x development.
--
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
16 years
[Hibernate-JIRA] Updated: (HHH-1851) relax special handling of 'id' property
by Anthony Patricio (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1851?page=c... ]
Anthony Patricio updated HHH-1851:
----------------------------------
Attachment: IdClassAndAnotherPropertyNamedId.zip
> relax special handling of 'id' property
> ---------------------------------------
>
> Key: HHH-1851
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1851
> Project: Hibernate3
> Issue Type: Improvement
> Components: query-hql
> Environment: independent, all versions all databases.
> Reporter: Gunther Schadow
> Assignee: Steve Ebersole
> Fix For: 3.2.2
>
> Attachments: IdClassAndAnotherPropertyNamedId.zip
>
>
> Hibernate has long treated 'id' in a special manner in HQL and Criteria queries. The drawback to this has always been that it effectively means users cannot define non-identifier properties named id and refer to those properties in HQL/Criteria queries.
> Thus, I will change this such that:
> (1) 'id' can still be used to refer to the identifier property, whatever the property's actual name, as long as the entity does not define a non-identitifer property named id.
> (2) if the entity defines a non-identifier property named 'id', using 'id' in HQL or Criteria queries will refer to this non-identifier property; users would need to refer to the identifier property by its actual name.
> FYI, the original reason for this feature was to support entity's which did not define an identifier property at all (users were responsible for managing the ids seperately. That feature was never really recommended and has been deprecated since early in the 3.x development.
--
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
16 years
[Hibernate-JIRA] Reopened: (HHH-1851) relax special handling of 'id' property
by Anthony Patricio (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1851?page=c... ]
Anthony Patricio reopened HHH-1851:
-----------------------------------
I think it's more efficient to reopen this issue than opening a new one as this problem is closely related.
It seems there is a special case where this problem isn't fixed: usage of composite id + another basic property named "id".
See attached entity and its IdClass.
When querying like "Select b from Bird b", following exception is thrown:
java.lang.NullPointerException
at org.hibernate.util.StringHelper.root(StringHelper.java:150)
at org.hibernate.persister.entity.AbstractEntityPersister.getSubclassPropertyTableNumber(AbstractEntityPersister.java:1374)
at org.hibernate.persister.entity.BasicEntityPropertyMapping.toColumns(BasicEntityPropertyMapping.java:31)
at org.hibernate.persister.entity.AbstractEntityPersister.toColumns(AbstractEntityPersister.java:1350)
at org.hibernate.hql.ast.tree.FromElement.getIdentityColumn(FromElement.java:296)
at org.hibernate.hql.ast.tree.IdentNode.resolveAsAlias(IdentNode.java:131)
at org.hibernate.hql.ast.tree.IdentNode.resolve(IdentNode.java:77)
at org.hibernate.hql.ast.tree.FromReferenceNode.resolve(FromReferenceNode.java:94)
at org.hibernate.hql.ast.tree.FromReferenceNode.resolve(FromReferenceNode.java:90)
at org.hibernate.hql.ast.HqlSqlWalker.resolve(HqlSqlWalker.java:728)
at org.hibernate.hql.antlr.HqlSqlBaseWalker.propertyRef(HqlSqlBaseWalker.java:1105)
at org.hibernate.hql.antlr.HqlSqlBaseWalker.selectExpr(HqlSqlBaseWalker.java:1881)
at org.hibernate.hql.antlr.HqlSqlBaseWalker.selectExprList(HqlSqlBaseWalker.java:1825)
at org.hibernate.hql.antlr.HqlSqlBaseWalker.selectClause(HqlSqlBaseWalker.java:1394)
at org.hibernate.hql.antlr.HqlSqlBaseWalker.query(HqlSqlBaseWalker.java:553)
at org.hibernate.hql.antlr.HqlSqlBaseWalker.selectStatement(HqlSqlBaseWalker.java:281)
at org.hibernate.hql.antlr.HqlSqlBaseWalker.statement(HqlSqlBaseWalker.java:229)
at org.hibernate.hql.ast.QueryTranslatorImpl.analyze(QueryTranslatorImpl.java:228)
at org.hibernate.hql.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:160)
at org.hibernate.hql.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:111)
at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:77)
at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:56)
at org.hibernate.engine.query.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:72)
at org.hibernate.impl.AbstractSessionImpl.getHQLQueryPlan(AbstractSessionImpl.java:133)
at org.hibernate.impl.AbstractSessionImpl.createQuery(AbstractSessionImpl.java:112)
at org.hibernate.impl.SessionImpl.createQuery(SessionImpl.java:1623)
at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:93)
at org.jboss.ejb3.entity.TransactionScopedEntityManager.createQuery(TransactionScopedEntityManager.java:127)
at case175572.Case175572TestCase.testCriteria(Case175572TestCase.java:96)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
> relax special handling of 'id' property
> ---------------------------------------
>
> Key: HHH-1851
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1851
> Project: Hibernate3
> Issue Type: Improvement
> Components: query-hql
> Environment: independent, all versions all databases.
> Reporter: Gunther Schadow
> Assignee: Steve Ebersole
> Fix For: 3.2.2
>
>
> Hibernate has long treated 'id' in a special manner in HQL and Criteria queries. The drawback to this has always been that it effectively means users cannot define non-identifier properties named id and refer to those properties in HQL/Criteria queries.
> Thus, I will change this such that:
> (1) 'id' can still be used to refer to the identifier property, whatever the property's actual name, as long as the entity does not define a non-identitifer property named id.
> (2) if the entity defines a non-identifier property named 'id', using 'id' in HQL or Criteria queries will refer to this non-identifier property; users would need to refer to the identifier property by its actual name.
> FYI, the original reason for this feature was to support entity's which did not define an identifier property at all (users were responsible for managing the ids seperately. That feature was never really recommended and has been deprecated since early in the 3.x development.
--
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
16 years
[Hibernate-JIRA] Commented: (HHH-1568) <subselect> returns stale data, <synchronize> doesn't evict <subselect> objects from session when session is flushed
by Hashim Kubba (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1568?page=c... ]
Hashim Kubba commented on HHH-1568:
-----------------------------------
I have opened a discussion under
Hibernate Forums Index -> Hibernate Users -> SubSelect stale data
I do believe this is a bug
See http://forum.hibernate.org/viewtopic.php?t=985811
> <subselect> returns stale data, <synchronize> doesn't evict <subselect> objects from session when session is flushed
> --------------------------------------------------------------------------------------------------------------------
>
> Key: HHH-1568
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1568
> Project: Hibernate3
> Issue Type: Bug
> Components: core
> Affects Versions: 3.1.2
> Environment: Oracle 10g, Java 5, Windows,
> Reporter: Greg Matthews
> Attachments: subselect_stale_data.log, SubselectTest.java
>
>
> Stale data is being returned from a select against a Hibernate class based on a <subselect> element (instead of a table).
> See detailed log info attached.
> A flush is occuring againt entities referenced within <synchronize> elements in the <subclass> based class, but a subsequent HQL query executed against the <subclass> based class still returns stale data. The log details show that the <subclass> object is retrieved from session.
> Our expectation is that it makes sense for Hibernate to automatically evict objects from session when synchronization causes other entities to be flushed -- otherwise, the whole <synchronization> mechanism is useless and you might as well do everything manually via various evict calls.
> e.g.
> If I have 2 mapping files, one for Table A, and another for a <subselect> based on Table A (let's call this View_A, then I will declare a <synchonized> element in View_A so that any changes to A are flushed before records from View_A are retrieved.
> This seems to work ok in that A is flushed when a query against View_A being executed, but subsequent retrieval of View_A gets loaded from Session, and not from the DB like we'd expect.
> If we manually evict the rows from View_A before executing the HQL query against View_A then up-to-date data is retrieved from View_A.
> Another strange thing is that if we *query* View_A after editing records from A, then the following message appears....
> 12:43:24 DEBUG org.hibernate.engine.ActionQueue.areTablesToUpdated - changes must be flushed to space: A
> ...but if we *load* a record from View_A then this message above does not appear. I would have thought any attempt to access View_A after updates to A had occurred would trigger a flush to A. Hopefully the flush occurs behind the scenes in all cases, and it's just a case of a missing log message in the case of doing a session.load().
--
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
16 years
[Hibernate-JIRA] Commented: (HHH-1134) subclass tag with discriminator in one to many mapping
by Thorsten Hilker (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1134?page=c... ]
Thorsten Hilker commented on HHH-1134:
--------------------------------------
@ForceDiscriminator does the trick.
see also http://forum.hibernate.org/viewtopic.php?t=961213
regards
Thorsten
> subclass tag with discriminator in one to many mapping
> ------------------------------------------------------
>
> Key: HHH-1134
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1134
> Project: Hibernate3
> Issue Type: Bug
> Components: core
> Environment: hibernate 3.0.5, Oracle
> Reporter: Dilip Ranjith
>
> Consider the following hbm.xml file
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE hibernate-mapping PUBLIC
> "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
> "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
> <hibernate-mapping
> >
> <class
> name="DCDTO"
> table="ACCDC"
> dynamic-update="true"
> >
> <id
> name="ID"
> type="java.lang.String"
> >
> <column
> name="DCINFOID"
> />
> <generator class="sequence">
> <param name="sequence">DSEQ</param>
> <!--
> To add non XDoclet generator parameters, create a file named
> hibernate-generator-params-DebtorCreditorDTO.xml
> containing the additional parameters and place it in your merge dir.
> -->
> </generator>
> </id>
> <discriminator
> column="accountType"
> not-null="true"
> type="java.lang.String"
> force="true"
> insert="true"
> />
> <property
> name="creditMax"
> type="java.lang.Double"
> update="true"
> insert="true"
> column="creditMax"
> />
> <subclass
> name="CDTO"
> dynamic-update="true"
> dynamic-insert="true"
> discriminator-value="C"
> >
> </.subclass>
> <subclass
> name="DDTO"
> dynamic-update="true"
> dynamic-insert="true"
> discriminator-value="D"
> >
> </.subclass>
> </class>
> </hibernate-mapping>
> DCDTO is the super class while DDTO and CDTO are its child classes
> If in a mapped object say TDTO there are a set of CDTOs and a separate set of DDTOs
> when we get TDTO the where clause "where accountType='D' " is not there when the query for set of DDTOs are generated. so instead of a set of DDTOs i am getting a set of both DDTO's and CDTO's
--
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
16 years
[Hibernate-JIRA] Created: (HHH-2523) informix 10 BLOB type
by Nick Airey (JIRA)
informix 10 BLOB type
---------------------
Key: HHH-2523
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2523
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.1
Environment: Hibernate 3.2.1
Informix Dynamic Server 10.00.FC5W4
IBM Informix JDBC Driver for IBM Informix Dynamic Server 3.00.JC2
Reporter: Nick Airey
Priority: Minor
Attachments: Informix10Dialect.java
Informix 10.0 and driver 3.0 supports the BLOB type, however the hibernate dialect file does not have this type registered.
Options for fixing would be to modify the existing InformixDialect, or (better) extend to a new class as per code snippet below, which is working fine for me.
package additional.hibernate;
import java.sql.Types;
import org.hibernate.dialect.InformixDialect;
/**
* @author Nick Airey
*/
public class Informix10Dialect extends InformixDialect {
public Informix10Dialect() {
super();
// register support for BLOB type in informix 10
registerColumnType( Types.BLOB, "blob" );
}
}
--
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
16 years
[Hibernate-JIRA] Created: (HHH-3242) <any> mappings don't work if the type field comes from a typedef
by nigel magnay (JIRA)
<any> mappings don't work if the type field comes from a typedef
----------------------------------------------------------------
Key: HHH-3242
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3242
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.6
Reporter: nigel magnay
Priority: Minor
If I have
<typedef name="oid_type" class="com.cswgroup.kms.hbm.OIDUserType"></typedef>
And a mapping containing
<any name="Resource" meta-type="long" id-type="oid_type">
I get an error :
Caused by: java.lang.NullPointerException
at org.hibernate.tuple.entity.EntityMetamodel.indicatesCollection(EntityMetamodel.java:392)
at org.hibernate.tuple.entity.EntityMetamodel.indicatesCollection(EntityMetamodel.java:398)
at org.hibernate.tuple.entity.EntityMetamodel.<init>(EntityMetamodel.java:215)
at org.hibernate.persister.entity.AbstractEntityPersister.<init>(AbstractEntityPersister.java:434)
at org.hibernate.persister.entity.SingleTableEntityPersister.<init>(SingleTableEntityPersister.java:109)
at org.hibernate.persister.PersisterFactory.createClassPersister(PersisterFactory.java:55)
at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:226)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1300)
at org.springframework.orm.hibernate3.LocalSessionFactoryBean.newSessionFactory(LocalSessionFactoryBean.java:805)
But if the mapping is changed to
<any name="Resource" meta-type="long" id-type="com.cswgroup.kms.hbm.OIDUserType">
Then it appears to work correctly.
--
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
16 years
[Hibernate-JIRA] Commented: (HHH-229) Filter failes on many-to-many relations
by Ryan Fowler (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-229?page=co... ]
Ryan Fowler commented on HHH-229:
---------------------------------
I'm having this problem and I get a "PERMISSION VIOLATION" when I click on the TODO-129. I also don't see a way to attach a file to this issue, so I'm pasting my patch into this comment. This seems to suite my purposes and the test case doesn't bomb out anymore but I'm not familiar enough with this code to guarantee correctness.
Index: src/org/hibernate/cfg/HbmBinder.java
===================================================================
--- src/org/hibernate/cfg/HbmBinder.java (revision 14512)
+++ src/org/hibernate/cfg/HbmBinder.java (working copy)
@@ -2940,6 +2940,15 @@
if ( condition==null) {
throw new MappingException("no filter condition found for filter: " + name);
}
+ // If this is a many-to-many association, add the filter as many-to-many
+ if(filterable instanceof Collection ) {
+ Collection c = (Collection)filterable;
+ if(!c.isOneToMany()) {
+ log.debug( "Applying ManyToMany filter [" + name + "] as [" + condition + "]" );
+ c.addManyToManyFilter(name, condition);
+ return;
+ }
+ }
log.debug( "Applying filter [" + name + "] as [" + condition + "]" );
filterable.addFilter( name, condition );
}
> Filter failes on many-to-many relations
> ---------------------------------------
>
> Key: HHH-229
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-229
> Project: Hibernate3
> Issue Type: Bug
> Affects Versions: 3.1 rc3
> Environment: Hibernate3 RC1
> Reporter: Magnus Sandberg
> Attachments: filterexample.zip
>
>
> When adding a filter to a class or one-to-many relation the filtering happens as expected. When adding a filter to a many-to-many relation (and I guess other relations using a join table) the columns in the filter-condition are mapped on the join table and not the associated table - the result is failure with exception.
--
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
16 years