[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-4732) Update Teradata Dialect for Teradata 13.0

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-4732?page=c... ] David Repshas commented on HHH-4732: ------------------------------------ Strong, I tried running org.hibernate.test.unionsubclass2.UnionSubclassTest to recreate your problem and did not hit the problem you encountered. Specifically, I didn't get an error for "HIBERNATE.UCustomer_0' already exists" though I did see the "Create Index" error which is a known limitation as Teradata requires an index field for this command. In the process of running this test I do see the following: - the use of constraints in Teradata does create the following two tables: UCUSTOMER_0 and UEMPLOYEE_0 - at the end of the test, I see this on the call stack: FunctionalTestClassTestSuite.tearDown:140 ExecutionEnvironment.complete:166 SessionFactoryImpl.close:887 SchemaExport:drop: 221 SchemaExport.execute:258 SchemaExport.drop:363 TeradataDialect.performDropPreProcess:326 1) The TeradataDialect:performDropPreProcess() method is passed the SQL: "alter table UCustomer drop constraint FK62B4BF5398311FBC" It then runs an executeQuery with this sql: sel IndexId, ChildTable, IndexName from dbc.RI_Distinct_ChildrenV where IndexName = 'FK62B4BF5398311FBC' It then returns the string: drop table "UCustomer_0" 2) Now after SchemaExport.drop() executes: alter table UCustomer drop constraint FK62B4BF5398311FBC" 3) the next call is to dialect.performDropPostProcess() which is passed the String: drop table "UCustomer_0" 4) this is run via executeUpdate and removes that table After this, a similar process occurs which removes the "UEMPLOYEE_0" table. I also ran the test until it created these tables: UCustomer, UCustomer_0, UEmployee and Uemployee_0 and then halted it. When I restarted the test, the tables UCustomer_0 and UCustomer_0 were successfully removed and the test ran to completion. If you delete the UCustomer_0 table and UEmployee_0 tables, you should be able to re-run this test. Could you set some breakpoints in TeradataDialect:performDropPreProcess() and TeradataDialect:performDropPostProcess() to ensure they are being called ?? At the end of a successful run, neither UCustomer_0 or UEmployee_0 should be present. Also, as noted above, the new dialect methods should generate and execute SQL to drop the tables that are causing the problems. My best guess right now is that: - the routines are not being called - the routines have a bug - the SQL they run is not working correctly Here's the official documentation on the error that was returned. It can be found in the Teradata Database Messages Manual: 5303 Error table '%VSTR' already exists. Explanation: Teradata system creates an error table to store target data rows that violate the specified referential constraint when the constraint is added to an existing table via ALTER TABLE statement or an inconsistent referential constraint is revalidated via REVALIDATE REFERENCES statement. The name of the error table is the target table name appended by the corresponding reference index number. If a table with that name has already existed in the system, then this error is returned. Generated By: RES modules. For Whom: End User. Remedy: Drop the table in conflict, and resubmit request. Dave -- 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