[Hibernate-JIRA] Created: (HHH-4120) hibernate failed to insert data into postgres partitioned table.
by sridhar (JIRA)
hibernate failed to insert data into postgres partitioned table.
----------------------------------------------------------------
Key: HHH-4120
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4120
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.1
Environment: RHEL 5.3, Postgres Standard server 8.3, JDK 1.6
Reporter: sridhar
Priority: Critical
Hibernate failed to insert data into tables when they are partitioned.
But there is no problem while doing the same operations with JDBC or throw SQL prompt.
The steps to reproduce the problem.
create tablespaces
----------------------------
CREATE TABLESPACE FPSDTS01 LOCATION '/postgres/PostgresPlus/8.3/data/tablespaces/FPSDTS01';
CREATE TABLESPACE FPSDTS02 LOCATION '/postgres/PostgresPlus/8.3/data/tablespaces/FPSDTS02';
create tables as below
-----------------------------------
CREATE TABLE coll_fp_submission_details(
rrid numeric NOT NULL,
sid numeric NOT NULL,
pfid numeric NOT NULL,
"timestamp" date NOT NULL,
schema_version numeric NOT NULL,
details character varying NOT NULL,
app_txn_id character varying NOT NULL,
CONSTRAINT coll_fp_submission_details_pkey PRIMARY KEY (rrid)
)
WITH (OIDS=FALSE);
CREATE TABLE coll_fp_subdtls_01
(
CONSTRAINT coll_fp_subdtls_01_pkey PRIMARY KEY (rrid)
)INHERITS (coll_fp_submission_details)
WITH (OIDS=FALSE)
TABLESPACE fpsdts01;
CREATE TABLE coll_fp_subdtls_02
(
CONSTRAINT coll_fp_subdtls_02_pkey PRIMARY KEY (rrid)
)
INHERITS (coll_fp_submission_details)
WITH (OIDS=FALSE)
TABLESPACE fpsdts02;
create a function
-----------------------
CREATE OR REPLACE FUNCTION ins_submission_details()
RETURNS TRIGGER AS $$
DECLARE
dateTable TEXT;
cmd TEXT;
BEGIN
IF ((NEW.rrid % 2)= 0) THEN
dateTable := 'coll_fp_subdtls_01';
ELSE
dateTable := 'coll_fp_subdtls_02';
END IF;
cmd := 'INSERT INTO ' || dateTable || '(rrid,sid,pfid,timestamp,schema_version,details,app_txn_id)' ||
' VALUES (' || quote_literal(NEW.rrid) || ',' ||
quote_literal(NEW.sid) || ',' ||
quote_literal(NEW.pfid) || ',' ||
quote_literal(NEW.timestamp) || ',' ||
quote_literal(NEW.schema_version) || ',' ||
quote_literal(NEW.details) || ',' ||
quote_literal(NEW.app_txn_id) || ')';
EXECUTE cmd;
RETURN NULL;
END;
$$LANGUAGE 'plpgsql';
create a trigger
--------------------
CREATE TRIGGER trig_ins_submission_details
BEFORE INSERT ON coll_fp_submission_details
FOR EACH ROW EXECUTE PROCEDURE ins_submission_details();
now say session.save(submissiondetails)
--
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, 9 months
[Hibernate-JIRA] Updated: (HHH-1123) Cannot put more than 1000 elements in a InExpression
by Alexis Seigneurin (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1123?page=c... ]
Alexis Seigneurin updated HHH-1123:
-----------------------------------
Attachment: hibernate-inexpression-oracle-3.2.patch
I just figured out that there was a bug in my original patch. When you had a multiple of 500 elements in the list, an invalid statement was generated. It looked like: property in ()
The new patch (named "hibernate-inexpression-oracle-3.2.patch") fixes that.
> Cannot put more than 1000 elements in a InExpression
> ----------------------------------------------------
>
> Key: HHH-1123
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1123
> Project: Hibernate Core
> Issue Type: Bug
> Components: core
> Affects Versions: 3.1 rc2, 3.2.0.alpha1
> Environment: Oracle 9i
> Reporter: Alexis Seigneurin
> Attachments: hibernate-inexpression-oracle-3.2.patch, patch.txt
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> The number of elements that we can put in a "in" expression is limited to a certain amount (1000 for Oracle, for instance). When creating a criteria query, the org.hibernate.criterion.InExpression class should split the expression into several smaller ones.
> Attached is a patch which splits the expression by slices of 500 elements. For example, if we have 1001 elements to put in the "in" expression, the result would be :
> (entity.field in (?, ?, ?...) or entity.field in (?, ?, ?...) or entity.field in (?))
> The surrounding parantheses are useful to avoid problems with other conditions (a "and" condition taking over the one of the "or" conditions).
--
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, 9 months
[Hibernate-JIRA] Commented: (HHH-1895) HqlSqlWalker throws NullPointerException with explicit joins and component mapping
by Victor Sergienko (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1895?page=c... ]
Victor Sergienko commented on HHH-1895:
---------------------------------------
I found that it's extremely easy to work around it: use "from table, table ... where" join instead of "join".
http://victorsergienko.com/hibernate-join-bug-createfromjoinelement/
> HqlSqlWalker throws NullPointerException with explicit joins and component mapping
> ----------------------------------------------------------------------------------
>
> Key: HHH-1895
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1895
> Project: Hibernate Core
> Issue Type: Bug
> Affects Versions: 3.1.3
> Environment: Oracle 9i, Hibernate 3.1.3
> Reporter: Victor Suarez
> Priority: Minor
>
> HqlSqlWalker throws a NPE if a explicit join is used with fields that are mapped with component mapping. If explicit join is removed and implicit join is used, the HQL works fine. This kind of problem didn't occur with Hibernate2.
> Examples (hbm below):
> The query:
> String query = "FROM " + Pais.class.getName() + " AS pais JOIN pais.metaInfo AS minfo WHERE minfo.activo = true";
> fails with this stacktrace:
> Exception in thread "main" java.lang.NullPointerException
> at org.hibernate.hql.ast.HqlSqlWalker.createFromJoinElement(HqlSqlWalker.java:317)
> at org.hibernate.hql.antlr.HqlSqlBaseWalker.joinElement(HqlSqlBaseWalker.java:3268)
> at org.hibernate.hql.antlr.HqlSqlBaseWalker.fromElement(HqlSqlBaseWalker.java:3060)
> at org.hibernate.hql.antlr.HqlSqlBaseWalker.fromElementList(HqlSqlBaseWalker.java:2938)
> at org.hibernate.hql.antlr.HqlSqlBaseWalker.fromClause(HqlSqlBaseWalker.java:688)
> at org.hibernate.hql.antlr.HqlSqlBaseWalker.query(HqlSqlBaseWalker.java:544)
> 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:218)
> at org.hibernate.hql.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:158)
> at org.hibernate.hql.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:109)
> at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:75)
> at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:54)
> at org.hibernate.engine.query.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:71)
> 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:1583)
> This one works fine:
> String query = "FROM " + Pais.class.getName() + " AS pais WHERE pais.metaInfo.activo = true";
> With this behaviour, HQL seems not to be totally transparent to mappings.
> Mapping file:
> <hibernate-mapping>
> <class name="Pais" table="Paises" lazy="true">
> <id name="id" type="long" column="id">
> <generator class="increment"/>
> </id>
> <component name="metaInfo" class="MetaInfo">
> <property name="usuarioAlta" column="usuarioAltaMetaInfo" type="string" not-null="false"/>
> <property name="fechaBaja" column="fechaBajaMetaInfo" type="timestamp" not-null="false"/>
> <property name="fechaAlta" column="fechaAltaMetaInfo" type="timestamp" not-null="false"/>
> <property name="activo" column="activoMetaInfo" type="boolean" not-null="false"/>
> <property name="usuarioBaja" column="usuarioBajaMetaInfo" type="string" not-null="false"/>
> </component>
> <property name="nombre" column="nombre" type="string" not-null="true"/>
> <property name="codigo" column="codigo" type="string" not-null="false"/>
>
> <set name="localidades" access="field" inverse="true"
> cascade="all-delete-orphan" lazy="true" batch-size="5">
> <key column="pais" />
> <one-to-many class="Localidad"/>
> </set>
> <set name="provincias" access="field" inverse="true"
> cascade="all-delete-orphan" lazy="true" batch-size="5">
> <key column="pais" />
> <one-to-many class="Provincia"/>
> </set>
>
> <property name="codAS400" type="string" not-null="false"/>
> </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
14 years, 9 months
[Hibernate-JIRA] Created: (HSEARCH-218) add indexAll( Class type ) to rebuild indexes from all data
by Sanne Grinovero (JIRA)
add indexAll( Class type ) to rebuild indexes from all data
-----------------------------------------------------------
Key: HSEARCH-218
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-218
Project: Hibernate Search
Issue Type: New Feature
Reporter: Sanne Grinovero
Assignee: Sanne Grinovero
The implementation should be as efficient as possible,
to cover this scenarios:
* Developers change an entity and want to test the effect on the index structure,
they want do to search experiments with the new fields.
* A production system is up(down)graded to a new(old) release,
involving index changes.
(the system is "down for maintenance" but the speed is crucial)
* Existing index is corrupted/lost. (Again, speed to recover is critical)
* A Database backup is restored, or data is changed by other jobs.
* Some crazy developer like me prefers to disable H.Search's event
listeners for some reason.
(I wouldn't generally recommend it, but have met other people who
have a reasonable argument to do this)
* A Lucene update breaks the index format (not so irrationale as they just did on trunk).
--
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, 9 months
[Hibernate-JIRA] Commented: (HHH-1287) Problem with WAS ExtendedJTATransaction not available when using MDB
by Purvin Patel (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1287?page=c... ]
Purvin Patel commented on HHH-1287:
-----------------------------------
This fix is in version 3.2.0.alpha2 and not in alpha1 as mentioned above.
> Problem with WAS ExtendedJTATransaction not available when using MDB
> --------------------------------------------------------------------
>
> Key: HHH-1287
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1287
> Project: Hibernate Core
> Issue Type: Bug
> Components: core
> Affects Versions: 3.1
> Environment: WAS 6.0.2
> Message Driven Bean (CMT)
> Websphere MQ 5.3
> Oracle 10g (thin XA driver)
> Reporter: dave jackson
> Assignee: Steve Ebersole
> Fix For: 3.2.0.alpha1, 3.1.3
>
>
> I'm currently having problems with the WAS6 ExtendedJTATransaction when using an MDB to update the database. The problem does not occur when using CMT SSBs.
> It looks like the ExtendedJTATransaction is simply not available after the CMT completes and the WebSphereExtendedJTATransactionLookup class attempts to look it up at java:comp/websphere/ExtendedJTATransaction as part of the normal 'after completion' callback.
> The problem occurs when the afterCompletion callback event fires and the ConnectionManager.isAggressiveRelease() method is called from ConnectionManager.afterTransaction(). This attempts to check to see if a transaction is in progress. This test in fact causes the transaction manager to be created (together with a look up of the current transaction) The lookup of the ExtendedJTATransaction fails and the an exception is thrown (see stack trace below).
> Although there may be an inconsistency in the way that a SSB and MDB operate, It seems fair to say that the transaction may not be available if it has completed. A workaround is therefore requested.
> Stack trace:
> [15/12/05 11:07:49:303 GMT] 0000003f RegisteredSyn E WTRN0074E: Exception caught from after_completion synchronization operation: org.hibernate.HibernateException: javax.naming.NameNotFoundException: Name comp/websphere not found in context "java:".
> at org.hibernate.transaction.WebSphereExtendedJTATransactionLookup$TransactionManagerAdapter$TransactionAdapter.<init>(WebSphereExtendedJTATransactionLookup.java:235)
> at org.hibernate.transaction.WebSphereExtendedJTATransactionLookup$TransactionManagerAdapter$TransactionAdapter.<init>(WebSphereExtendedJTATransactionLookup.java:215)
> at org.hibernate.transaction.WebSphereExtendedJTATransactionLookup$TransactionManagerAdapter.getTransaction(WebSphereExtendedJTATransactionLookup.java:163)
> at org.hibernate.util.JTAHelper.isTransactionInProgress(JTAHelper.java:36)
> at org.hibernate.jdbc.JDBCContext.isTransactionInProgress(JDBCContext.java:180)
> at org.hibernate.jdbc.ConnectionManager.isAggressiveRelease(ConnectionManager.java:142)
> at org.hibernate.jdbc.ConnectionManager.afterTransaction(ConnectionManager.java:189)
> at org.hibernate.jdbc.JDBCContext.afterTransactionCompletion(JDBCContext.java:213)
> at org.hibernate.transaction.CacheSynchronization.afterCompletion(CacheSynchronization.java:85)
> at org.hibernate.transaction.WebSphereExtendedJTATransactionLookup$1.invoke(WebSphereExtendedJTATransactionLookup.java:265)
> at $Proxy30.afterCompletion(Unknown Source)
> at com.ibm.ws.jtaextensions.SynchronizationCallbackWrapper.afterCompletion(SynchronizationCallbackWrapper.java:74)
> at com.ibm.ws.Transaction.JTA.RegisteredSyncs.distributeAfter(RegisteredSyncs.java(Compiled Code))
> at com.ibm.ws.Transaction.JTA.TransactionImpl.distributeAfter(TransactionImpl.java:3652)
> at com.ibm.ws.Transaction.JTA.TransactionImpl.postCompletion(TransactionImpl.java:3631)
> at com.ibm.ws.Transaction.JTA.TransactionImpl.internalCommit(TransactionImpl.java:2522)
> at com.ibm.ws.Transaction.JTA.TransactionImpl.stage2CommitProcessing(TransactionImpl.java:1609)
> at com.ibm.ws.Transaction.JTA.TransactionImpl.processCommit(TransactionImpl.java:1483)
> at com.ibm.ws.Transaction.JTA.TransactionImpl.commit(TransactionImpl.java:1414)
> at com.ibm.ws.Transaction.JTA.TranManagerImpl.commit(TranManagerImpl.java:236)
> at com.ibm.ws.Transaction.JTA.TranManagerSet.commit(TranManagerSet.java:157)
> at com.ibm.ejs.csi.TranStrategy.commit(TranStrategy.java:716)
> at com.ibm.ejs.csi.TranStrategy.postInvoke(TranStrategy.java:167)
> at com.ibm.ejs.csi.TransactionControlImpl.postInvoke(TransactionControlImpl.java:569)
> at com.ibm.ejs.container.EJSContainer.postInvoke(EJSContainer.java(Compiled Code))
> at com.ibm.ejs.container.MDBWrapper.onMessage(MDBWrapper.java:102)
> at com.ibm.ejs.container.MDBWrapper.onMessage(MDBWrapper.java:127)
> at com.ibm.ejs.jms.listener.ServerSession.run(ServerSession.java:458)
> at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1455)
> Caused by: javax.naming.NameNotFoundException: Name comp/websphere not found in context "java:".
> at com.ibm.ws.naming.ipbase.NameSpace.getParentCtxInternal(NameSpace.java(Compiled Code))
> at com.ibm.ws.naming.ipbase.NameSpace.lookupInternal(NameSpace.java(Compiled Code))
> at com.ibm.ws.naming.ipbase.NameSpace.lookup(NameSpace.java(Inlined Compiled Code))
> at com.ibm.ws.naming.urlbase.UrlContextImpl.lookup(UrlContextImpl.java(Compiled Code))
> at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java(Compiled Code))
> at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java(Compiled Code))
> at javax.naming.InitialContext.lookup(InitialContext.java(Compiled Code))
> at org.hibernate.transaction.WebSphereExtendedJTATransactionLookup$TransactionManagerAdapter$TransactionAdapter.<init>(WebSphereExtendedJTATransactionLookup.java:227)
> ... 28 more
--
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, 9 months