Mailing-List: contact derby-commits-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: svn commit: r670778 - in /db/derby/code/trunk/java:
 engine/org/apache/derby/iapi/types/DataTypeDescriptor.java
 testing/org/apache/derbyTesting/functionTests/tests/lang/TriggerTest.java
Date: Mon, 23 Jun 2008 21:42:24 -0000
To: derby-commits@db.apache.org
From: mamta@apache.org
Message-Id: <20080623214224.46F9823889C2@eris.apache.org>

Author: mamta
Date: Mon Jun 23 14:42:23 2008
New Revision: 670778

URL: http://svn.apache.org/viewvc?rev=670778&view=rev
Log:
DERBY-3718

Derby has an internal datatype called REF. For REF datatypes, we associate Types.OTHER as it's type. This
 association of Types.OTHER for REF datatype is causing NPE when a row level trigger is fired in the test 
case provided in DERBY-3718.

This NPE happens only in 10.4 and trunk. This is because starting 10.4(DERBY-2917 revision r619995),
rather than saving the TypeId of the DataTypeDescriptor (in DataTypeDescriptor.writeExternal method), we
rely on reconstructing TypeId (in readExternal) by using the Types.xxx associated with a type. This 
approach does not work for internal datatype REF, because we use Types.OTHER for REF datatypes. 
Types.OTHER is not enough to know that the type to be constructed is REF.  

Since we are dealing with the internal type which will be assigned a Types.OTHER type then we can't rely on Types.xxx to get us the correct data type. This fix relies on using the name of the data type rather 
than it's Type.xxx to construct the correct TypeId. This is being accomplised by changing 
DataTypeDescriptor.readExternal to use this.getTypeName rather than this.getJDBCTypeId to construct the TypeId. In addition to this change, I had to change DataTypeDescriptor.getTypeName() to use TypeDescriptor to get the type name rather than TypeId. This is because TypeId is not available when DataTypeDescriptor.readExternal calls DataTypeDescriptor.getTypeName. This will match how we already implement DataTypeDescriptor.getJDBCTypeId(). Junit and old harness suite have run with no new regressions. 


Modified:
    db/derby/code/trunk/java/engine/org/apache/derby/iapi/types/DataTypeDescriptor.java
    db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/lang/TriggerTest.java

Modified: db/derby/code/trunk/java/engine/org/apache/derby/iapi/types/DataTypeDescriptor.java
URL: http://svn.apache.org/viewvc/db/derby/code/trunk/java/engine/org/apache/derby/iapi/types/DataTypeDescriptor.java?rev=670778&r1=670777&r2=670778&view=diff
==============================================================================
--- db/derby/code/trunk/java/engine/org/apache/derby/iapi/types/DataTypeDescriptor.java (original)
+++ db/derby/code/trunk/java/engine/org/apache/derby/iapi/types/DataTypeDescriptor.java Mon Jun 23 14:42:23 2008
@@ -1036,7 +1036,7 @@
 	 */
 	public	String		getTypeName()
 	{
-		return typeId.getSQLTypeName();
+		return typeDescriptor.getTypeName();
 	}
 
 	/**
@@ -1753,7 +1753,7 @@
 	{
 		typeDescriptor = (TypeDescriptorImpl) in.readObject();
         
-        typeId = TypeId.getBuiltInTypeId(this.getJDBCTypeId());
+        typeId = TypeId.getBuiltInTypeId(this.getTypeName());
         
         collationDerivation = in.readInt();
 	}

Modified: db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/lang/TriggerTest.java
URL: http://svn.apache.org/viewvc/db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/lang/TriggerTest.java?rev=670778&r1=670777&r2=670778&view=diff
==============================================================================
--- db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/lang/TriggerTest.java (original)
+++ db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/lang/TriggerTest.java Mon Jun 23 14:42:23 2008
@@ -399,6 +399,46 @@
     {
         ((List) TRIGGER_INFO.get()).add(info);  
     }
+
+    /** 
+     * Test for DERBY-3718 NPE when a trigger is fired
+     * 
+     * @throws SQLException
+     * @throws IOException
+     */
+    public void testNPEinTriggerFire() throws SQLException
+    {
+        Statement s = createStatement();
+        
+    	String sql = " CREATE TABLE TRADE(ID INT PRIMARY KEY GENERATED "+
+    	"BY DEFAULT AS IDENTITY (START WITH 1000), BUYID INT NOT NULL," +
+    	"QTY FLOAT(2) NOT NULL)";
+        s.executeUpdate(sql);
+
+        sql = "CREATE TABLE TOTAL(BUYID INT NOT NULL, TOTALQTY FLOAT(2) NOT NULL)";
+        s.executeUpdate(sql);
+        
+        sql = "CREATE TRIGGER TRADE_INSERT AFTER INSERT ON TRADE REFERENCING "+ 
+        "NEW AS NEWROW FOR EACH ROW MODE DB2SQL UPDATE TOTAL SET TOTALQTY "+
+        "= NEWROW.QTY WHERE BUYID = NEWROW.BUYID"; 
+        s.executeUpdate(sql);
+        
+        s.executeUpdate("INSERT INTO TOTAL VALUES (1, 0)");
+        //Before DERBY-3718 was fixed, following would cause NPE in 10.4 and 
+        //trunk. This happened because starting 10.4, rather than saving the
+        //TypeId of the DataTypeDescriptor (in writeExternal method), we rely
+        //on reconstructing TypeId (in readExternal) by using the Types.xxx 
+        //information(DERBY-2917 revision r619995). This approach does not
+        //work for internal datatype REF, because we use Types.OTHER for REF
+        //datatypes. Types.OTHER is not enough to know that the type to be 
+        //constructed is REF. 
+        //To get around the problem, for reconstructing TypeId, we will
+        //use the type name rather than Types.xxx. Since we have the correct
+        //type name for internal datatype REF, we can successfully reconstruct
+        //REF datatype. 
+        s.executeUpdate("INSERT INTO TRADE VALUES(1, 1, 10)");
+        commit();      
+    }
     
     /** 
      * Test for DERBY-3238 trigger fails with IOException if triggering table has large lob.