[Hibernate-JIRA] Commented: (HHH-1675) identity generators withy Postgres 8
by Dylan (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1675?page=c... ]
Dylan commented on HHH-1675:
----------------------------
I found this in PostgreSQLDialect.java:
public String getIdentityColumnString(int type) {
return type==Types.BIGINT ?
"bigserial not null" :
"serial not null";
}
and also
public String getSelectSequenceNextValString(String sequenceName) {
return "nextval ('" + sequenceName + "')";
}
So it looks me like this feature is intentional.
Adding this to the docs would be good.
> identity generators withy Postgres 8
> ------------------------------------
>
> Key: HHH-1675
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1675
> Project: Hibernate3
> Issue Type: Improvement
> Components: core, documentation
> Affects Versions: 3.1
> Environment: Hibernate 3 and Postgres 8, linux
> Reporter: Robin Demetriades
> Original Estimate: 0 minutes
> Remaining Estimate: 0 minutes
>
> I have recently noticed that specifying a generator class = "identity" actually works
> in Postgres as well when the Primary key is of type SERIAL. This however is not reflected in the
> documentation and indeed may just be a happy coincidence rather than by design.
> My improvement request is that this feature be maintained, and even if possible the use of
> the Postgres DEFAULT keyword used as a generator class in the hibernate-mapping XML.
> This undocumented feature has the advantage of skipping an extra database call (as opposed to when generator="sequence") and allowing me to have a unique sequence per table if I so wish so I would be sorry to see it lost as the codebase progresses.
> Rgds,
> Robin Demetriades
--
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
17 years, 2 months
[Hibernate-JIRA] Commented: (HHH-40) Filter and Positional Parameters Bound in Incorrect Order
by Shawn Clowater (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-40?page=com... ]
Shawn Clowater commented on HHH-40:
-----------------------------------
Julien, take a look at http://opensource.atlassian.com/projects/hibernate/browse/HHH-530
I've submitted a patch there to address the same type of issue for when filters are applied to subqueries. Strangely enough it is pretty much like the original patch that I submitted for this report. I don't even remember opening this one.
Anyways, try the patch from 530 and see if it fixes your issue as well. The gist of the patch is to bind the parameters as they appear whether they are positional or filter parameters.
> Filter and Positional Parameters Bound in Incorrect Order
> ---------------------------------------------------------
>
> Key: HHH-40
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-40
> Project: Hibernate3
> Issue Type: Patch
> Affects Versions: 3.0 alpha
> Environment: Oracle 9i, 3.0 Alpha CVS as of Nov 17, 2004.
> Reporter: Shawn Clowater
> Assignee: Steve Ebersole
> Fix For: 3.0 beta 1
>
> Attachments: patch.diff
>
>
> When combining a filter at a top level class with a criteria paramater (positional) it was possible that the parameters would be bound in the wrong order.
> i.e. the following filter at the class level
> <filter name="versionFilter" condition="((:effectiveDate BETWEEN CREATE_DATE AND CREATE_DATE OR :inactiveDate BETWEEN CREATE_DATE AND CREATE_DATE))"/>
> <filter-def name="versionFilter">
> <filter-param name="effectiveDate" type="java.util.Date"/>
> <filter-param name="inactiveDate" type="java.util.Date"/>
> </filter-def>
> combined with a simple criteria parameter results in
> DEBUG [AWT-EventQueue-0] (NullableType.java:46) - binding '2004-08-01 00:00:00' to parameter: 1
> DEBUG [AWT-EventQueue-0] (NullableType.java:46) - binding '2004-08-31 23:59:59' to parameter: 2
> DEBUG [AWT-EventQueue-0] (NullableType.java:46) - binding '4' to parameter: 3
> DEBUG [AWT-EventQueue-0] (AbstractBatcher.java:260) - about to close PreparedStatement (open PreparedStatements: 1, globally: 1)
> DEBUG [AWT-EventQueue-0] (AbstractBatcher.java:361) - closing statement
> DEBUG [AWT-EventQueue-0] (JDBCExceptionReporter.java:50) - could not execute query [select this_.AGMT_CNTRCT_LINE_ID as AGMT_CNT1_3_, this_.AGMT_CNTRCT_ID as AGMT_CNT2_18_3_, this_.NOTES_ID as NOTES_ID18_3_, this_.UPDATE_DATE as UPDATE_D4_18_3_, this_.CREATE_DATE as CREATE_D5_18_3_, this_.UPDATE_USER as UPDATE_U6_18_3_, this_.CREATE_USER as CREATE_U7_18_3_, agmtcontra_.AGMT_CNTRCT_ID as AGMT_CNT1_0_, agmtcontra_.AGMT_ID as AGMT_ID16_0_, agmtcontra_.NOTES_ID as NOTES_ID16_0_, agmtcontra_.UPDATE_DATE as UPDATE_D4_16_0_, agmtcontra_.CREATE_DATE as CREATE_D5_16_0_, agmtcontra_.UPDATE_USER as UPDATE_U6_16_0_, agmtcontra_.CREATE_USER as CREATE_U7_16_0_, acversionj_.AGMT_CNTRCT_V_ID as AGMT_CNT1_1_, acversionj_.AGMT_CNTRCT_ID as AGMT_CNT2_17_1_, acversionj_.CNTRCT_SEQ as CNTRCT_SEQ17_1_, acversionj_.CNTRCT_REVISION as CNTRCT_R4_17_1_, acversionj_.AGMT_CNTRCT_TYPE_ID as AGMT_CNT5_17_1_, acversionj_.CNTRCT_REF as CNTRCT_REF17_1_, acversionj_.DESCRIPTION as DESCRIPT7_17_1_, acversionj_.QTY_VOLUME_TYPE_CODE as QTY_VOLU8_17_1_, acversionj_.QTY_LIMIT_FLG as QTY_LIMI9_17_1_, acversionj_.EFFECTIVE_DATE as EFFECTI10_17_1_, acversionj_.INACTIVE_DATE as INACTIV11_17_1_, acversionj_.UPDATE_DATE as UPDATE_12_17_1_, acversionj_.CREATE_DATE as CREATE_13_17_1_, acversionj_.UPDATE_USER as UPDATE_14_17_1_, acversionj_.CREATE_USER as CREATE_15_17_1_, acversionj_.ACTIVE_FLG as ACTIVE_FLG17_1_, aclversion_.AGMT_CNTRCT_LINE_V_ID as AGMT_CNT1_2_, aclversion_.AGMT_CNTRCT_LINE_ID as AGMT_CNT2_23_2_, aclversion_.QTY_LIMIT_ENFORCED_FLG as QTY_LIMI3_23_2_, aclversion_.DESCRIPTION as DESCRIPT4_23_2_, aclversion_.BUYER_STKHLDR_ID as BUYER_ST5_23_2_, aclversion_.SELLER_STKHLDR_ID as SELLER_S6_23_2_, aclversion_.SHIPPER_STKHLDR_ID as SHIPPER_7_23_2_, aclversion_.SRC_ADDR_ID as SRC_ADDR8_23_2_, aclversion_.SRC_INVENTORY_ID as SRC_INVE9_23_2_, aclversion_.DEST_ADDR_ID as DEST_AD10_23_2_, aclversion_.DEST_INVENTORY_ID as DEST_IN11_23_2_, aclversion_.DELIVERY_POINT_ADDR_ID as DELIVER12_23_2_, aclversion_.TITLE_TRANSFER_ADDR_ID as TITLE_T13_23_2_, aclversion_.SHIP_MODE_CODE as SHIP_MO14_23_2_, aclversion_.SHIP_TERMS as SHIP_TERMS23_2_, aclversion_.PRIORITY as PRIORITY23_2_, aclversion_.END_USE_CODE as END_USE17_23_2_, aclversion_.QTY_CALC_METHOD as QTY_CAL18_23_2_, aclversion_.NOMINATION_TYPE as NOMINAT19_23_2_, aclversion_.BEFORE_AFTER_IND as BEFORE_20_23_2_, aclversion_.IN_TRANSIT_FLG as IN_TRAN21_23_2_, aclversion_.ROUTING_ID as ROUTING_ID23_2_, aclversion_.EXCHANGE_PROCESS_FLG as EXCHANG23_23_2_, aclversion_.BACKFLOW_FLG as BACKFLO24_23_2_, aclversion_.COSTING_SRC_FLG as COSTING25_23_2_, aclversion_.DEDUCTION_LIMIT as DEDUCTI26_23_2_, aclversion_.QTY as QTY23_2_, aclversion_.QTY_UOM_CODE as QTY_UOM28_23_2_, aclversion_.ENERGY as ENERGY23_2_, aclversion_.ENERGY_UOM_CODE as ENERGY_30_23_2_, aclversion_.QTY_GAIN_LOSS_INDEX_PRICE_ID as QTY_GAI31_23_2_, aclversion_.EFFECTIVE_DATE as EFFECTI32_23_2_, aclversion_.INACTIVE_DATE as INACTIV33_23_2_, aclversion_.UPDATE_DATE as UPDATE_34_23_2_, aclversion_.CREATE_DATE as CREATE_35_23_2_, aclversion_.UPDATE_USER as UPDATE_36_23_2_, aclversion_.CREATE_USER as CREATE_37_23_2_, aclversion_.ACTIVE_FLG as ACTIVE_FLG23_2_ from AGMT_CNTRCT_LINE this_ inner join AGMT_CNTRCT agmtcontra_ on this_.AGMT_CNTRCT_ID=agmtcontra_.AGMT_CNTRCT_ID inner join AGMT_CNTRCT_V acversionj_ on agmtcontra_.AGMT_CNTRCT_ID=acversionj_.AGMT_CNTRCT_ID inner join AGMT_CNTRCT_LINE_V aclversion_ on this_.AGMT_CNTRCT_LINE_ID=aclversion_.AGMT_CNTRCT_LINE_ID where acversionj_.AGMT_CNTRCT_TYPE_ID=? and ((:versionFilter.effectiveDate BETWEEN this_.CREATE_DATE AND this_.CREATE_DATE OR :versionFilter.inactiveDate BETWEEN this_.CREATE_DATE AND this_.CREATE_DATE))]
> java.sql.SQLException: ORA-00932: inconsistent datatypes: expected NUMBER got DATE
>
> at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:134)
> at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:289)
> at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:579)
> at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1894)
> at oracle.jdbc.ttc7.TTC7Protocol.parseExecuteDescribe(TTC7Protocol.java:831)
> at oracle.jdbc.driver.OracleStatement.doExecuteQuery(OracleStatement.java:2496)
> at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:2840)
> at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:608)
> at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:536)
> at org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:103)
> at org.hibernate.loader.Loader.getResultSet(Loader.java:1065)
> at org.hibernate.loader.Loader.doQuery(Loader.java:344)
> at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:190)
> at org.hibernate.loader.Loader.doList(Loader.java:1271)
> at org.hibernate.loader.Loader.list(Loader.java:1254)
> at org.hibernate.loader.CriteriaLoader.list(CriteriaLoader.java:169)
> at org.hibernate.impl.SessionImpl.find(SessionImpl.java:2100)
> at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:274)
> at com.entero.enterovision.framework.service.AbstractService.fetch(AbstractService.java:340)
> at com.entero.enterovision.framework.service.AbstractService.fetch(AbstractService.java:315)
> at com.entero.enterovision.framework.service.AbstractService.fetch(AbstractService.java:281)
> at com.entero.enterovision.service.agmt.AgmtService.fetchAgmtContractLines(AgmtService.java:488)
> at com.entero.enterovision.components.agreementitemprice.AgreementController.find(AgreementController.java:71)
> at com.entero.enterovision.components.AbstractController.findByParameters(AbstractController.java:32)
> at com.entero.enterovision.components.ActiveWorkbench.populate(ActiveWorkbench.java:329)
> at com.entero.enterovision.components.AbstractPMAWorkbench.populate(AbstractPMAWorkbench.java:30)
> at com.entero.enterovision.components.AbstractSidebarSearchPanel.populateWorkbench(AbstractSidebarSearchPanel.java:241)
> at com.entero.enterovision.components.agreementitemprice.AgreementItemPriceSearchSidebar.find(AgreementItemPriceSearchSidebar.java:203)
> at com.entero.infrastructure.ui.sidebar.SidebarPanel.executeFunction(SidebarPanel.java:158)
> at com.entero.enterovision.components.AbstractSidebarSearchPanel.search(AbstractSidebarSearchPanel.java:183)
> at com.entero.enterovision.components.AbstractSidebarSearchPanel.access$000(AbstractSidebarSearchPanel.java:32)
> at com.entero.enterovision.components.AbstractSidebarSearchPanel$2.actionPerformed(AbstractSidebarSearchPanel.java:112)
> at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1786)
> at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1839)
> at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420)
> at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258)
> at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:245)
> at java.awt.Component.processMouseEvent(Component.java:5100)
> at java.awt.Component.processEvent(Component.java:4897)
> at java.awt.Container.processEvent(Container.java:1569)
> at java.awt.Component.dispatchEventImpl(Component.java:3615)
> at java.awt.Container.dispatchEventImpl(Container.java:1627)
> at java.awt.Component.dispatchEvent(Component.java:3477)
> at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3483)
> at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3198)
> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3128)
> at java.awt.Container.dispatchEventImpl(Container.java:1613)
> at java.awt.Window.dispatchEventImpl(Window.java:1606)
> at java.awt.Component.dispatchEvent(Component.java:3477)
> at java.awt.EventQueue.dispatchEvent(EventQueue.java:456)
> at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:201)
> at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:151)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:145)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:137)
> at java.awt.EventDispatchThread.run(EventDispatchThread.java:100)
> WARN [AWT-EventQueue-0] (JDBCExceptionReporter.java:58) - SQL Error: 932, SQLState: 42000
> ERROR [AWT-EventQueue-0] (JDBCExceptionReporter.java:59) - ORA-00932: inconsistent datatypes: expected NUMBER got DATE
> -----
> Note how the parameters were applied in the wrong order. This was due to the Loader class in the processFilterParameters() method ALWAYS putting the filter parameters at the front of the queue. It is even more pronounced if you have additional filters further on down the chain.
--
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
17 years, 2 months
[Hibernate-JIRA] Commented: (HHH-40) Filter and Positional Parameters Bound in Incorrect Order
by Julien HENRY (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-40?page=com... ]
Julien HENRY commented on HHH-40:
---------------------------------
Hi,
I'm using Hibernate 3.2.5, and it seems I have the same problem.
The only difference is I'm applying the filter in a set of component.
<hibernate-mapping package="com.capgemini.myproject.beans">
<class name="Employee" schema="LAE" table="LAE_ANNUAIRE">
<cache usage="read-only"/>
<id name="sia" column="PER_SIA"/>
<property name="firstname" column="PER_PNO"/>
<property name="lastname" column="PER_NOM"/>
<set name="roles" table="LAE_ROLE" schema="LAE">
<key column="PER_SIA"/>
<element type="string" column="ROLE_COD"/>
<filter name="appFilter" condition=":appCode = app_cod"/>
</set>
</class>
<filter-def name="appFilter">
<filter-param name="appCode" type="string" />
</filter-def>
</hibernate-mapping>
Here is the query:
session.enableFilter("appFilter").setParameter("appCode", appCode);
return session.createQuery("from Employee where :role = some elements(roles)").setString("role", role).list();
And here is the logs:
/*
from
Employee
where
:role = some elements(roles) */ select
empl0_.per_sia as per1_2_,
empl0_.per_pno as per2_2_,
templ0_.per_nom as per3_2_
from
LAE.lae_annuaire empl0_
where
?=some (
select
roles1_.role_cod
from
LAE.lae_role roles1_
where
empl0_.per_sia=roles1_.per_sia
and ? = roles1_.app_cod
)
5875 DEBUG [main] org.hibernate.jdbc.AbstractBatcher : preparing statement
5985 DEBUG [main] org.hibernate.type.StringType : binding 'APP1' to parameter: 1
5985 DEBUG [main] org.hibernate.type.StringType : binding 'Administrator' to parameter: 2
> Filter and Positional Parameters Bound in Incorrect Order
> ---------------------------------------------------------
>
> Key: HHH-40
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-40
> Project: Hibernate3
> Issue Type: Patch
> Affects Versions: 3.0 alpha
> Environment: Oracle 9i, 3.0 Alpha CVS as of Nov 17, 2004.
> Reporter: Shawn Clowater
> Assignee: Steve Ebersole
> Fix For: 3.0 beta 1
>
> Attachments: patch.diff
>
>
> When combining a filter at a top level class with a criteria paramater (positional) it was possible that the parameters would be bound in the wrong order.
> i.e. the following filter at the class level
> <filter name="versionFilter" condition="((:effectiveDate BETWEEN CREATE_DATE AND CREATE_DATE OR :inactiveDate BETWEEN CREATE_DATE AND CREATE_DATE))"/>
> <filter-def name="versionFilter">
> <filter-param name="effectiveDate" type="java.util.Date"/>
> <filter-param name="inactiveDate" type="java.util.Date"/>
> </filter-def>
> combined with a simple criteria parameter results in
> DEBUG [AWT-EventQueue-0] (NullableType.java:46) - binding '2004-08-01 00:00:00' to parameter: 1
> DEBUG [AWT-EventQueue-0] (NullableType.java:46) - binding '2004-08-31 23:59:59' to parameter: 2
> DEBUG [AWT-EventQueue-0] (NullableType.java:46) - binding '4' to parameter: 3
> DEBUG [AWT-EventQueue-0] (AbstractBatcher.java:260) - about to close PreparedStatement (open PreparedStatements: 1, globally: 1)
> DEBUG [AWT-EventQueue-0] (AbstractBatcher.java:361) - closing statement
> DEBUG [AWT-EventQueue-0] (JDBCExceptionReporter.java:50) - could not execute query [select this_.AGMT_CNTRCT_LINE_ID as AGMT_CNT1_3_, this_.AGMT_CNTRCT_ID as AGMT_CNT2_18_3_, this_.NOTES_ID as NOTES_ID18_3_, this_.UPDATE_DATE as UPDATE_D4_18_3_, this_.CREATE_DATE as CREATE_D5_18_3_, this_.UPDATE_USER as UPDATE_U6_18_3_, this_.CREATE_USER as CREATE_U7_18_3_, agmtcontra_.AGMT_CNTRCT_ID as AGMT_CNT1_0_, agmtcontra_.AGMT_ID as AGMT_ID16_0_, agmtcontra_.NOTES_ID as NOTES_ID16_0_, agmtcontra_.UPDATE_DATE as UPDATE_D4_16_0_, agmtcontra_.CREATE_DATE as CREATE_D5_16_0_, agmtcontra_.UPDATE_USER as UPDATE_U6_16_0_, agmtcontra_.CREATE_USER as CREATE_U7_16_0_, acversionj_.AGMT_CNTRCT_V_ID as AGMT_CNT1_1_, acversionj_.AGMT_CNTRCT_ID as AGMT_CNT2_17_1_, acversionj_.CNTRCT_SEQ as CNTRCT_SEQ17_1_, acversionj_.CNTRCT_REVISION as CNTRCT_R4_17_1_, acversionj_.AGMT_CNTRCT_TYPE_ID as AGMT_CNT5_17_1_, acversionj_.CNTRCT_REF as CNTRCT_REF17_1_, acversionj_.DESCRIPTION as DESCRIPT7_17_1_, acversionj_.QTY_VOLUME_TYPE_CODE as QTY_VOLU8_17_1_, acversionj_.QTY_LIMIT_FLG as QTY_LIMI9_17_1_, acversionj_.EFFECTIVE_DATE as EFFECTI10_17_1_, acversionj_.INACTIVE_DATE as INACTIV11_17_1_, acversionj_.UPDATE_DATE as UPDATE_12_17_1_, acversionj_.CREATE_DATE as CREATE_13_17_1_, acversionj_.UPDATE_USER as UPDATE_14_17_1_, acversionj_.CREATE_USER as CREATE_15_17_1_, acversionj_.ACTIVE_FLG as ACTIVE_FLG17_1_, aclversion_.AGMT_CNTRCT_LINE_V_ID as AGMT_CNT1_2_, aclversion_.AGMT_CNTRCT_LINE_ID as AGMT_CNT2_23_2_, aclversion_.QTY_LIMIT_ENFORCED_FLG as QTY_LIMI3_23_2_, aclversion_.DESCRIPTION as DESCRIPT4_23_2_, aclversion_.BUYER_STKHLDR_ID as BUYER_ST5_23_2_, aclversion_.SELLER_STKHLDR_ID as SELLER_S6_23_2_, aclversion_.SHIPPER_STKHLDR_ID as SHIPPER_7_23_2_, aclversion_.SRC_ADDR_ID as SRC_ADDR8_23_2_, aclversion_.SRC_INVENTORY_ID as SRC_INVE9_23_2_, aclversion_.DEST_ADDR_ID as DEST_AD10_23_2_, aclversion_.DEST_INVENTORY_ID as DEST_IN11_23_2_, aclversion_.DELIVERY_POINT_ADDR_ID as DELIVER12_23_2_, aclversion_.TITLE_TRANSFER_ADDR_ID as TITLE_T13_23_2_, aclversion_.SHIP_MODE_CODE as SHIP_MO14_23_2_, aclversion_.SHIP_TERMS as SHIP_TERMS23_2_, aclversion_.PRIORITY as PRIORITY23_2_, aclversion_.END_USE_CODE as END_USE17_23_2_, aclversion_.QTY_CALC_METHOD as QTY_CAL18_23_2_, aclversion_.NOMINATION_TYPE as NOMINAT19_23_2_, aclversion_.BEFORE_AFTER_IND as BEFORE_20_23_2_, aclversion_.IN_TRANSIT_FLG as IN_TRAN21_23_2_, aclversion_.ROUTING_ID as ROUTING_ID23_2_, aclversion_.EXCHANGE_PROCESS_FLG as EXCHANG23_23_2_, aclversion_.BACKFLOW_FLG as BACKFLO24_23_2_, aclversion_.COSTING_SRC_FLG as COSTING25_23_2_, aclversion_.DEDUCTION_LIMIT as DEDUCTI26_23_2_, aclversion_.QTY as QTY23_2_, aclversion_.QTY_UOM_CODE as QTY_UOM28_23_2_, aclversion_.ENERGY as ENERGY23_2_, aclversion_.ENERGY_UOM_CODE as ENERGY_30_23_2_, aclversion_.QTY_GAIN_LOSS_INDEX_PRICE_ID as QTY_GAI31_23_2_, aclversion_.EFFECTIVE_DATE as EFFECTI32_23_2_, aclversion_.INACTIVE_DATE as INACTIV33_23_2_, aclversion_.UPDATE_DATE as UPDATE_34_23_2_, aclversion_.CREATE_DATE as CREATE_35_23_2_, aclversion_.UPDATE_USER as UPDATE_36_23_2_, aclversion_.CREATE_USER as CREATE_37_23_2_, aclversion_.ACTIVE_FLG as ACTIVE_FLG23_2_ from AGMT_CNTRCT_LINE this_ inner join AGMT_CNTRCT agmtcontra_ on this_.AGMT_CNTRCT_ID=agmtcontra_.AGMT_CNTRCT_ID inner join AGMT_CNTRCT_V acversionj_ on agmtcontra_.AGMT_CNTRCT_ID=acversionj_.AGMT_CNTRCT_ID inner join AGMT_CNTRCT_LINE_V aclversion_ on this_.AGMT_CNTRCT_LINE_ID=aclversion_.AGMT_CNTRCT_LINE_ID where acversionj_.AGMT_CNTRCT_TYPE_ID=? and ((:versionFilter.effectiveDate BETWEEN this_.CREATE_DATE AND this_.CREATE_DATE OR :versionFilter.inactiveDate BETWEEN this_.CREATE_DATE AND this_.CREATE_DATE))]
> java.sql.SQLException: ORA-00932: inconsistent datatypes: expected NUMBER got DATE
>
> at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:134)
> at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:289)
> at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:579)
> at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1894)
> at oracle.jdbc.ttc7.TTC7Protocol.parseExecuteDescribe(TTC7Protocol.java:831)
> at oracle.jdbc.driver.OracleStatement.doExecuteQuery(OracleStatement.java:2496)
> at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:2840)
> at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:608)
> at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:536)
> at org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:103)
> at org.hibernate.loader.Loader.getResultSet(Loader.java:1065)
> at org.hibernate.loader.Loader.doQuery(Loader.java:344)
> at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:190)
> at org.hibernate.loader.Loader.doList(Loader.java:1271)
> at org.hibernate.loader.Loader.list(Loader.java:1254)
> at org.hibernate.loader.CriteriaLoader.list(CriteriaLoader.java:169)
> at org.hibernate.impl.SessionImpl.find(SessionImpl.java:2100)
> at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:274)
> at com.entero.enterovision.framework.service.AbstractService.fetch(AbstractService.java:340)
> at com.entero.enterovision.framework.service.AbstractService.fetch(AbstractService.java:315)
> at com.entero.enterovision.framework.service.AbstractService.fetch(AbstractService.java:281)
> at com.entero.enterovision.service.agmt.AgmtService.fetchAgmtContractLines(AgmtService.java:488)
> at com.entero.enterovision.components.agreementitemprice.AgreementController.find(AgreementController.java:71)
> at com.entero.enterovision.components.AbstractController.findByParameters(AbstractController.java:32)
> at com.entero.enterovision.components.ActiveWorkbench.populate(ActiveWorkbench.java:329)
> at com.entero.enterovision.components.AbstractPMAWorkbench.populate(AbstractPMAWorkbench.java:30)
> at com.entero.enterovision.components.AbstractSidebarSearchPanel.populateWorkbench(AbstractSidebarSearchPanel.java:241)
> at com.entero.enterovision.components.agreementitemprice.AgreementItemPriceSearchSidebar.find(AgreementItemPriceSearchSidebar.java:203)
> at com.entero.infrastructure.ui.sidebar.SidebarPanel.executeFunction(SidebarPanel.java:158)
> at com.entero.enterovision.components.AbstractSidebarSearchPanel.search(AbstractSidebarSearchPanel.java:183)
> at com.entero.enterovision.components.AbstractSidebarSearchPanel.access$000(AbstractSidebarSearchPanel.java:32)
> at com.entero.enterovision.components.AbstractSidebarSearchPanel$2.actionPerformed(AbstractSidebarSearchPanel.java:112)
> at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1786)
> at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1839)
> at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420)
> at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258)
> at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:245)
> at java.awt.Component.processMouseEvent(Component.java:5100)
> at java.awt.Component.processEvent(Component.java:4897)
> at java.awt.Container.processEvent(Container.java:1569)
> at java.awt.Component.dispatchEventImpl(Component.java:3615)
> at java.awt.Container.dispatchEventImpl(Container.java:1627)
> at java.awt.Component.dispatchEvent(Component.java:3477)
> at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3483)
> at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3198)
> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3128)
> at java.awt.Container.dispatchEventImpl(Container.java:1613)
> at java.awt.Window.dispatchEventImpl(Window.java:1606)
> at java.awt.Component.dispatchEvent(Component.java:3477)
> at java.awt.EventQueue.dispatchEvent(EventQueue.java:456)
> at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:201)
> at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:151)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:145)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:137)
> at java.awt.EventDispatchThread.run(EventDispatchThread.java:100)
> WARN [AWT-EventQueue-0] (JDBCExceptionReporter.java:58) - SQL Error: 932, SQLState: 42000
> ERROR [AWT-EventQueue-0] (JDBCExceptionReporter.java:59) - ORA-00932: inconsistent datatypes: expected NUMBER got DATE
> -----
> Note how the parameters were applied in the wrong order. This was due to the Loader class in the processFilterParameters() method ALWAYS putting the filter parameters at the front of the queue. It is even more pronounced if you have additional filters further on down the chain.
--
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
17 years, 2 months
[Hibernate-JIRA] Commented: (HHH-1797) <set> inside of a <join>
by Nicolas De Cubber (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1797?page=c... ]
Nicolas De Cubber commented on HHH-1797:
----------------------------------------
The solution is to move the <set> outside the <join>, like this :
<subclass name="LicensePlateSuspend" discriminator-value="license plate suspend">
<set name="licensePlates">
<key>
<column name="licensePlateSuspendId"/>
<column name="licensePlate"/>
</key>
<one-to-many class="LicensePlate"/>
</set>
<join table="LicensePlateSuspend">
<key column="licensePlateSuspendId"/>
</join>
</subclass>
> <set> inside of a <join>
> ------------------------
>
> Key: HHH-1797
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1797
> Project: Hibernate3
> Issue Type: Improvement
> Components: core, metamodel
> Environment: n/a
> Reporter: Michael Masters
>
> I want to be able to use the following mapping. The problem I face is that a <set> cannot exist in a <join>.
> <?xml version="1.0"?>
> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
> <hibernate-mapping package="com.digitaldarwin.hibernate.model">
> <class name="Event" table="Event">
> <id name="id" column="eventId">
> <generator class="native">
> <param name="sequence">event_eventid_seq</param>
> </generator>
> </id>
> <discriminator column="eventType" type="string"/>
> <subclass name="Enforcement" discriminator-value="enforcement">
> <join table="Enforcement">
> <key column="eventId"/>
> <property name="name" column="name"/>
> </join>
> </subclass>
> <subclass name="LicensePlateSuspend" discriminator-value="license plate suspend">
> <join table="LicensePlateSuspend">
> <key column="licensePlateSuspendId"/>
> <set name="licensePlates">
> <key>
> <column name="licensePlateSuspendId"/>
> <column name="licensePlate"/>
> </key>
> <one-to-many class="LicensePlate"/>
> </set>
> </join>
> </subclass>
> </class>
> </hibernate-mapping>
--
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
17 years, 2 months
[Hibernate-JIRA] Created: (HHH-2200) Memory leak in AbstractBatcher with Generated Properties
by Jay Paulsen (JIRA)
Memory leak in AbstractBatcher with Generated Properties
--------------------------------------------------------
Key: HHH-2200
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2200
Project: Hibernate3
Type: Bug
Versions: 3.2.0.ga
Environment: Hibernate 3.2.0 GA; Oracle 10g; Java 1.5
Reporter: Jay Paulsen
Using Hibernate 3.2 GA with Entity Manager and Annotations, I have a batch job that inserts several thousands of objects for a class with a @Generated property. The job results in a memory leak in the AbstractBatcher class.
The problem appears to be in the method processGeneratedProperties in AbstractEntityPersister. This method closes the result set for the generated property query and calls session.getBatcher().closeStatement() to close the statement instead of session.getBatcher().closeQueryStatement to close both the statement and the result set. The result is that even though the result set is closed, it is not removed AbstractBatcher's resultSetsToClose HashSet.
Even though the batch job commits and clears the session every 200 rows, over time the leaked result sets in resultSetsToClose results in an OutOfMemory problem.
I've changed the code in AbstractEntityPersister.processGeneratedProperties to call session.getBatcher().closeQueryStatement and the same job then runs to completion without the memory leakage.
I noticed that this method in AbstractEntityPersister has had a recent change to fix a similar problem for issue HHH-1750, so I wanted to verify that this fix is the right approach.
--
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
17 years, 2 months
[Hibernate-JIRA] Commented: (HHH-530) Allow application of filters on subqueries
by Shawn Clowater (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-530?page=co... ]
Shawn Clowater commented on HHH-530:
------------------------------------
Gail, I've added a patch which adds some tests to the DynamicFilterTest suite. (This was against the 3.2.5 release as that is where I have my code patched to currently)
First 2 are relatively straight forward, search with a valid filter find 1, search with an invalid filter find none.
The 3rd one is a little more complex and then the 4th one was supposed to include a subquery within a subquery with filters at both levels.
However, I found an issue with the way I'm getting at the filters to pass to the CriteriaJoinWalker. I'm casting the criteria to a CriteriaImpl to get at the session but in the nested subquery it's no longer a CriteriaImpl it is a CriteriaImpl$Subcriteria.
There doesn't seem to be a mechanism right now to be able to get at that in all cases, the parent criteria on the Subcriteria doesn't have a reference to the actual session (it was null when I tried it).
> Allow application of filters on subqueries
> ------------------------------------------
>
> Key: HHH-530
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-530
> Project: Hibernate3
> Issue Type: Patch
> Components: core
> Reporter: Gavin King
> Assignee: Steve Ebersole
> Fix For: 3.3
>
> Attachments: HHH-530.patch, hibernate_filter_fix-3.0.5.patch, hibernate_filter_fix-3.0.5_14.patch, SubqueriesWithFiltersTest.patch
>
>
> Currently filter conditions are applied in subselects, they should not be.
--
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
17 years, 2 months
[Hibernate-JIRA] Created: (HHH-2078) for update on multiple tables does not work or is not present. cascade='lock' does not always work as specified.
by Peter Mutsaers (JIRA)
for update on multiple tables does not work or is not present. cascade='lock' does not always work as specified.
----------------------------------------------------------------------------------------------------------------
Key: HHH-2078
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2078
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.1.3
Environment: Oracle 9
Reporter: Peter Mutsaers
A normal one to many relationship between two classes, say A and B exists.
We have a cascade='lock' from A to B and also specified fetch='join'.
When I get only an instance of A, hibernate generates a left join between A and B.
When I get the instance while getting a lock, session.get(A.class, id, LockMode.UPGRADE),
I would expect and need an SQL statement along the lines of "select .. from A a left join B b on a.id=b.a_id FOR UPDATE", which would lock both A and its associated B instances.
Instead, hibernate even refuses to execute the join in this case, and fetches A and B with separate queries.
Also whatever I do, I cannot convince hibernate to generate a "for update" query without specifiying a specific table.
For example when A and B have fetch="select" and B is lazily loaded, and I have already retrieved an instance of A, then execute
session.lock(a, id, LockMode.UPGRADE), I would expect that the cascade='lock' would also lock B by either generating the left join over A and B, or by executing both "select ... from A for update" and "select ... from B for update".
Instead, only the first select statement is executed and B is NOT LOCKED at all in spite of the cascade='lock' instruction.
--
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
17 years, 2 months