[Hibernate-JIRA] Commented: (HHH-1134) subclass tag with discriminator in one to many mapping
by Bob Petry (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1134?page=c... ]
Bob Petry commented on HHH-1134:
--------------------------------
Your comment :[The reasoning is that you should not reuse the same FK column for 2 different relationships, which is what is done here.]
is a dificult for me to understand.
I am facing the same problem, where multiple one to many relationships from PojoA to multiple different subclassed Pojos (PojoC, PojoD, PojoE, where C, D and E are subclasses of PojoB) exist.
Can you explain to me why a single column (with a foreign key to the ID of PojoA) in the PojoB table that stores my subclassed Pojos, should not be done.
I don't think this is an unreasonable situation.
It seems silly to have a separate column for each subclass type, where each reference the id of PojoA.
This seems like a bug to me that would have a simple fix. It seems like simply performing, an instanceof on each of the SubClass types (until the proper type is identified) rather than casting to the first type that is loaded would solve the issue.
Am I correct or is this issue and the proper solution more convoluted?
> 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, 3 months
[Hibernate-JIRA] Created: (HHH-3098) hbm2ddl=validate and "missing table" on Oracle10g
by Daniel Baryla (JIRA)
hbm2ddl=validate and "missing table" on Oracle10g
-------------------------------------------------
Key: HHH-3098
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3098
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5.GA, Hibernate Annotations 3.3.0.GA, Oracle 10g (10.2.0.1.0), WebLogic 9.2 (JDK 1.5).
Reporter: Daniel Baryla
Attachments: bug-attachment.zip
I've got a database with some tables. Everything is mapped to Hibernate using classic HBM files. The problem is Hibernate reports missing table (DYSPOZYCJA_DOKUMENTY) even though the table exists and it seems to be mapped correctly. If you take a look on attached log file you will see Hibernate validated a couple of tables before reporting DYSPOZYCJA_DOKUMENTY is missing. I've done a test: removed table BIURO_MAKLERSKIE and redeployed my application - Hibernate reported BIURO_MAKLERSKIE is missing (which is correct of course).
Note that I've tried to init Hibernate without [new Configuration().configure().buildSessionFactory()] and with Hibernate Annotations [new AnnotationConfiguration().configure().buildSessionFactory()] - results are the same.
I've attached:
- hibernate log
- ddl, source and mapping files for 2 tables (BIURO_MAKLERSKIE and DYSPOZYCJA_DOKUMENTY)
- hibernate configuration file
- source for HibernateUtil I use to intialize Hibernate
--
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, 3 months
[Hibernate-JIRA] Created: (HHH-3084) DialectFactory.java doesn't map the IngresDialect
by Michael Leo (JIRA)
DialectFactory.java doesn't map the IngresDialect
-------------------------------------------------
Key: HHH-3084
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3084
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.5, 3.2.4.sp1, 3.2.4, 3.2.3, 3.2.2, 3.2.1, 3.2.0.ga, 3.2.0.cr5, 3.2.0.cr4, 3.2.0.cr3, 3.2.0.cr2, 3.2.0 cr1, 3.1.3, 3.2.0.alpha2, 3.2.0.alpha1, 3.1.2, 3.1.1, 3.1, 3.1 rc3, 3.1 rc2, 3.1 rc 1, 3.1 beta 2, 3.1 beta 1, 3.0.5, 3.0.4, 3.0.3, 3.0.2, 3.0.1, 3.0 final, 3.0 rc 1, 3.0 beta 4, 3.0 beta 3, 3.0 beta 2, 3.0 beta 1, 3.0 alpha
Environment: Hibernate 3.x and frameworks based on the Spring Framework, like Grails
Reporter: Michael Leo
Attachments: DialectFactory.java.patch
Although Hibernate ships with an Ingres dialect
org.hibernate.dialect.IngresDialect
it can't be found by the dialect factory
org.hibernate.dialect.DialectFactory
Although most tools can be forced to use the proper dialect, there is a circumstance
in Grails where there is no way to specify the correct Hibernate dialect for a custom
data source.
The patch is pretty straightforward. I've attached the output of "svn diff" from the
root of the latest branch.
Hope this makes sense,
Mike Leo
$ svn diff
Index: src/org/hibernate/dialect/DialectFactory.java
===================================================================
--- src/org/hibernate/dialect/DialectFactory.java (revision 14289)
+++ src/org/hibernate/dialect/DialectFactory.java (working copy)
@@ -112,6 +112,9 @@
private static final Map MAPPERS = new HashMap();
static {
// TODO : this is the stuff it'd be nice to move to a properties file or some other easily user-editable place
+ MAPPERS.put( "Ingres", new VersionInsensitiveMapper( "org.hibernate.dialect.IngresDialect" ) );
+ MAPPERS.put( "ingres", new VersionInsensitiveMapper( "org.hibernate.dialect.IngresDialect" ) );
+ MAPPERS.put( "INGRES", new VersionInsensitiveMapper( "org.hibernate.dialect.IngresDialect" ) );
MAPPERS.put( "HSQL Database Engine", new VersionInsensitiveMapper( "org.hibernate.dialect.HSQLDialect" ) );
MAPPERS.put( "DB2/NT", new VersionInsensitiveMapper( "org.hibernate.dialect.DB2Dialect" ) );
MAPPERS.put( "DB2/LINUX", new VersionInsensitiveMapper( "org.hibernate.dialect.DB2Dialect" ) );
$
--
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, 3 months
[Hibernate-JIRA] Resolved: (HHH-1956) Interceptor.afterTransactionCompletion not called with JTATransaction (CacheSynchronization.hibernateTransaction not set)
by Steve Ebersole (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1956?page=c... ]
Steve Ebersole resolved HHH-1956.
---------------------------------
Resolution: Fixed
trunk / 3.2
the code which registers the Hibernate synch was changed to also now create a Hibernate Transaction instance at the same time...
> Interceptor.afterTransactionCompletion not called with JTATransaction (CacheSynchronization.hibernateTransaction not set)
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: HHH-1956
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1956
> Project: Hibernate3
> Issue Type: Bug
> Components: core
> Affects Versions: 3.1.2
> Environment: JBoss 4.0.3SP1 under Windows XP
> Reporter: Eric Sword
> Assignee: Steve Ebersole
> Fix For: 3.2.6, 3.3
>
>
> interceptor.afterTransactionCompletion should be invoked in SessionImpl.afterTransactionCompletion, but it is only called if the tx parameter is not null. When running under a JTA environment, that parameter will always be null. This is the stack which leads to the call (line numbers are from v3.1.2 code):
> org.hibernate.impl.SessionImpl.afterTransactionCompletion(boolean, org.hibernate.Transaction) line: 442
> org.hibernate.jdbc.JDBCContext.afterTransactionCompletion(boolean, org.hibernate.Transaction) line: 205
> org.hibernate.transaction.CacheSynchronization.afterCompletion(int) line: 85
> org.jboss.tm.TransactionImpl.doAfterCompletion() line: 1508
> org.jboss.tm.TransactionImpl.completeTransaction() line: 1180
> org.jboss.tm.TransactionImpl.commit() line: 359
> org.jboss.tm.TxManager.commit() line: 224
> org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit() line: 126
> org.hibernate.transaction.JTATransaction.commit() line: 146
> The problem is that the hibernateTransaction member variable of the CacheSynchronization object is never set. Here is the call stack for how that object is created:
> org.hibernate.transaction.CacheSynchronization.<init>(org.hibernate.transaction.TransactionFactory$Context, org.hibernate.jdbc.JDBCContext, javax.transaction.Transaction, org.hibernate.Transaction) line: 34
> org.hibernate.jdbc.JDBCContext.registerSynchronizationIfPossible() line: 149
> org.hibernate.transaction.JTATransaction.begin() line: 102
> org.hibernate.impl.SessionImpl.beginTransaction() line: 1309
> com.osc.util.hibernate.HibernateManager.getSession(org.hibernate.Interceptor) line: 204
> You can see in the JDBCContext.registerSynchronizationIfPossible() method that the parameter to set the transaction is always null, even though the JDBCContext object does have a reference to the hibernateTransaction at that point. The CacheSynchronization only uses that reference for beforeTransactionCompletion and afterTransactionCompletion calls. The beforeTransactionCompletion works because the SessionImpl.beforeTransactionCompletion call doesn't check if the tx is null, while the afterTransactionCompletion does.
--
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, 3 months
[Hibernate-JIRA] Commented: (HHH-1615) GROUP BY entity does not work
by Giampaolo Tomassoni (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1615?page=c... ]
Giampaolo Tomassoni commented on HHH-1615:
------------------------------------------
I have the impression your example is a bit misleading. Grouped queries in which you need to get a whole entity are generally ones in which some ORM is involveld, otherwise the "group by" construct is redundant.
In example, the HQL query:
SELECT c, COUNT(*)
FROM Company AS c INNER JOIN c.products AS p
WHERE p.price > 150.00
GROUP BY c
HAVING COUNT(*) > 1
ORDER BY c.income ASC
could be mapped by a patched Hibernate to something like, say, the following SQL select:
SELECT c.id, c.name, c.income, COUNT(*)
FROM companies AS c RIGHT OUTER JOIN products AS p ON c.id=p.idcompany
WHERE p.price > 150.00
GROUP BY c.id, c.name, c.income
HAVING COUNT(*) > 1
ORDER BY c.income ASC
I think that many SQL optimizers should discover the speed-up pattern available on this kind of redundanly-grouped queries: c.id is a primary key and the value of c.name and c.income depend on it. Pheraps MySQL misses a true query optimizer?
Anyway, in order to improve performances when the optimizer isn't smart enough, the trick in SQL is field post-fetching. In example, a patched Hibernate could instead map the above HQL query in the following SQL one:
SELECT c1.id, c1.name, c1.income, c2.cnt
FROM companies AS c1 RIGHT OUTER JOIN (
SELECT c.id, COUNT(*) AS cnt
FROM companies AS c INNER JOIN products AS p ON c.id=p.idcompany
WHERE p.price > 150.00
GROUP BY c.id
HAVING cnt > 1
) AS c2 ON c1.id=c.id
ORDER BY c1.income ASC
See? The HQL query is basically mimed by the inner select, which is then wrapped by one meant mostly to dereference entity fields. This needs a grouping index having the same width of the company table's primary key (1 assumed in this example), and results in better performances with respect to fetching all the grouped data in the application and then dereferencing the IDs from there.
It needs subqueries and joins, besides. I don't know if MySQL does support subqueries, but most of the other SQL engines handled by Hibernate do.
So, a general solution to the problem outlined in this issue would be to adopt the subquery+joins mapping when the target SQL engine supports them, falling back to the multi-field grouping when it doesn't.
Please note I didn't run the above HQL and SQL queries, thereby it may be there is something wrong in them.
> GROUP BY entity does not work
> -----------------------------
>
> Key: HHH-1615
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1615
> Project: Hibernate3
> Issue Type: Improvement
> Components: query-hql
> Affects Versions: 3.2.5
> Environment: PostgreSQL 8.1.3, Hibernate 3.1.3
> Reporter: Xavier Bugaud
> Assignee: Anthony Patricio
> Priority: Critical
> Attachments: hibernate-group-by.diff
>
>
> The query : "select cat, count(*) from Cat cat group by cat" does not work.
> ERROR: column "xxxx" must appear in the GROUP BY clause or be used in an aggregate function
> See :
> - http://forum.hibernate.org/viewtopic.php?t=953716
> - http://jira.nhibernate.org/browse/NH-528
--
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, 3 months
[Hibernate-JIRA] Commented: (HHH-1615) GROUP BY entity does not work
by Sandeep Tamhankar (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1615?page=c... ]
Sandeep Tamhankar commented on HHH-1615:
----------------------------------------
Agreed. I couldn't live with this when I ran into it, so I tweaked Hibernate and attached a patch to this bug. If you need this functionality, try out my patch.
That said, doing this can make for really slow query execution in MySQL, and in the end I stopped doing queries like the examples above in my app and instead do id queries followed by object queries.
select c
from Cat c, ...
where ...
group by c
having ...
order by ...
=>
select c.id
from Cat c, ...
where ...
group by c.id
having ...
order by ...
select c
from Cat c
where c.id in (id1, id2, ...)
This is more work in the application:
1. If you care about order, you need to keep track of the id query result order so that you can rejigger the results from the object query.
2. There's a limit on how many ids you can supply in the object query predicate. So you may need to do multiple object queries and re-order results as you go.
But this is generally quite fast because the queries should be using the primary key index....well, it's not that simple either. Fields in the order by clause must be in the group by as well (not sure if this is true for MySQL, but it's true for some db's that my app has to work with). In any case, fewer fields in group by clause means you need smaller indices to support the queries, so overall performance is much better.
> GROUP BY entity does not work
> -----------------------------
>
> Key: HHH-1615
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1615
> Project: Hibernate3
> Issue Type: Improvement
> Components: query-hql
> Affects Versions: 3.2.5
> Environment: PostgreSQL 8.1.3, Hibernate 3.1.3
> Reporter: Xavier Bugaud
> Assignee: Anthony Patricio
> Priority: Critical
> Attachments: hibernate-group-by.diff
>
>
> The query : "select cat, count(*) from Cat cat group by cat" does not work.
> ERROR: column "xxxx" must appear in the GROUP BY clause or be used in an aggregate function
> See :
> - http://forum.hibernate.org/viewtopic.php?t=953716
> - http://jira.nhibernate.org/browse/NH-528
--
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, 3 months
[Hibernate-JIRA] Commented: (HHH-1830) Error during parse query on MS SQL
by Emmanuel Bernard (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1830?page=c... ]
Emmanuel Bernard commented on HHH-1830:
---------------------------------------
It's not a problem per se, just add some work on our side. Steve, Gail or I would have to translate your case into hbm files to inject it into the test suite. Hibernate Core is fully independent of annotations.
> Error during parse query on MS SQL
> ----------------------------------
>
> Key: HHH-1830
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1830
> Project: Hibernate3
> Issue Type: Bug
> Affects Versions: 3.1.2, 3.2.0.cr2
> Environment: Microsoft SQL Server 2000, Windows XP, JDK 1.5 Update 4
> Reporter: Den Raskovalov
> Priority: Critical
> Attachments: hibernateBug.tar.gz
>
>
> HQL: select deal, items.dateBegin, client.Title from " + CoreDeal.class.getName() + " deal left join deal.stagesWorkflowInstance.history.items items, " + CoreClient.class.getName() + " client where stageResponsible=:stageResponsible and items.index=maxindex(items) and deal.parent=client and deal.stagesWorkflowInstance.Stage.showOnPersonalPage=1
> It works normally on Oracle, but on MS SQL produces:
> Error: String index out of range: -5
> [java.lang.StringIndexOutOfBoundsException]
> java.lang.String.substring(String.java:1768)
> java.lang.String.substring(String.java:1735)
> org.hibernate.hql.CollectionSubqueryFactory.createCollectionSubquery(CollectionSubqueryFactory.java:32)
> org.hibernate.hql.ast.tree.FromElementType.toColumns(FromElementType.java:301)
> org.hibernate.hql.ast.tree.FromElementType.toColumns(FromElementType.java:291)
> org.hibernate.hql.ast.tree.FromElement.toColumns(FromElement.java:377)
> org.hibernate.hql.ast.tree.MethodNode.resolveCollectionProperty(MethodNode.java:115)
> org.hibernate.hql.ast.tree.MethodNode.collectionProperty(MethodNode.java:95)
> org.hibernate.hql.ast.tree.MethodNode.resolve(MethodNode.java:44)
> org.hibernate.hql.ast.HqlSqlWalker.processFunction(HqlSqlWalker.java:844)
> org.hibernate.hql.antlr.HqlSqlBaseWalker.functionCall(HqlSqlBaseWalker.java:2324)
> org.hibernate.hql.antlr.HqlSqlBaseWalker.expr(HqlSqlBaseWalker.java:1285)
> org.hibernate.hql.antlr.HqlSqlBaseWalker.exprOrSubquery(HqlSqlBaseWalker.java:4032)
> org.hibernate.hql.antlr.HqlSqlBaseWalker.comparisonExpr(HqlSqlBaseWalker.java:3521)
> org.hibernate.hql.antlr.HqlSqlBaseWalker.logicalExpr(HqlSqlBaseWalker.java:1758)
> org.hibernate.hql.antlr.HqlSqlBaseWalker.logicalExpr(HqlSqlBaseWalker.java:1686)
> org.hibernate.hql.antlr.HqlSqlBaseWalker.logicalExpr(HqlSqlBaseWalker.java:1683)
> org.hibernate.hql.antlr.HqlSqlBaseWalker.logicalExpr(HqlSqlBaseWalker.java:1683)
> org.hibernate.hql.antlr.HqlSqlBaseWalker.whereClause(HqlSqlBaseWalker.java:776)
> org.hibernate.hql.antlr.HqlSqlBaseWalker.query(HqlSqlBaseWalker.java:577)
> org.hibernate.hql.antlr.HqlSqlBaseWalker.selectStatement(HqlSqlBaseWalker.java:281)
> org.hibernate.hql.antlr.HqlSqlBaseWalker.statement(HqlSqlBaseWalker.java:229)
> org.hibernate.hql.ast.QueryTranslatorImpl.analyze(QueryTranslatorImpl.java:227)
> org.hibernate.hql.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:159)
> org.hibernate.hql.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:110)
> org.hibernate.engine.query.HQLQueryPlan.(HQLQueryPlan.java:77)
> org.hibernate.engine.query.HQLQueryPlan.(HQLQueryPlan.java:56)
> org.hibernate.engine.query.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:71)
> org.hibernate.impl.AbstractSessionImpl.getHQLQueryPlan(AbstractSessionImpl.java:133)
> org.hibernate.impl.AbstractSessionImpl.createQuery(AbstractSessionImpl.java:112)
> org.hibernate.impl.SessionImpl.createQuery(SessionImpl.java:1612)
> ru.naumen.crm2.bobjects.deal.CoreDealHibernateHandler.listAllDealsWithSortDataByResponsible(CoreDealHibernateHandler.java:109)
> ru.naumen.crm2.ui.tlc.CoreEmployeeTableListController.listMyDealsSorted(CoreEmployeeTableListController.java:70)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
--
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, 3 months