Exporter hbm2hbmxml fails with duplicate class name error

WallyHartshorn · **Joined:** Tue Feb 20, 2007 4:14 pm **Posts:** 8

I'm trying to use Hibernate's reverse engineering feature to generate the mapping files for an existing Oracle database. I'm using Oracle 8.1.17, Java 5, Hibernate 3.2, and Eclipse 3.2.

The Ant task runs for several minutes, then fails with the following message:

Quote:

An exception occurred while running exporter #2:hbm2hbmxml (Generates a set of hbm.xml files)
To get the full stack trace run ant with -verbose
org.hibernate.cfg.JDBCBinderException: Duplicate class name 'FooBar' generated for 'org.hibernate.mapping.Table(FOO_BAR_)'. Same name where generated for 'org.hibernate.mapping.Table(FOO_BAR_)'

There are two tables named "FOO_BAR_", but they appear to be in two separate schemas. (They at least have two different owners, which I'm assuming means the same thing, but I'm not very familiar with Oracle.)

I'm telling Hibernate to deal with just the one schema, but it appears to be ignoring that. Or am I wrong about different owners implying different schemas? Can a single schema have two tables with the same name?

If I add a table filter to limit the tables to those with names matching, saying, "XYZZY.*", then the reveng task completes successfully, but of course it doesn't get the "FOO_BAR_" table.

Here is some.db.properties:

Quote:

hibernate.dialect = org.hibernate.dialect.OracleDialect
hibernate.connection.driver_class = oracle.jdbc.driver.OracleDriver
hibernate.connection.username = foo
hibernate.connection.password = bar
hibernate.connection.url = jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS = (PROTOCOL = TCP)(HOST = 1.2.3.4)(PORT = 1521)))(CONNECT_DATA=(SERVICE_NAME=foo)(SERVER=DEDICATED)))
hibernate.default_schema = foo

Here is some.reveng.xml:

Quote:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-reverse-engineering SYSTEM
"http://hibernate.sourceforge.net/hibernate-reverse-engineering-3.0.dtd">
<hibernate-reverse-engineering>
<schema-selection match-schema="foo" />
<table-filter match-schema="foo" match-name=".*" package="foo.bar" />
</hibernate-reverse-engineering>

Sixel · **Posted:** Thu Mar 01, 2007 8:52 am

I don't know if it's related, but I once struggled with this Exception, and the workaround I found was to explicitly define a rule for the "duplicate" table, that is, in your some.reveng.xml file, adding the following line BEFORE the one with the wildcard.

Code:

<table-filter match-schema="foo" match-name="FOO_BAR_" exclude="false" />

Hope this helps,
alexis

WallyHartshorn · **Joined:** Tue Feb 20, 2007 4:14 pm **Posts:** 8

Thanks for the suggestion, but I tried it and found that it didn't help. It's strange. Thanks again!

max · **Posted:** Mon Mar 19, 2007 11:00 am

are you 100% sure you are not processing more than one schema with the same table name used twice ?

if not I would like to get a minimal testcase for it in jira.

WallyHartshorn · **Joined:** Tue Feb 20, 2007 4:14 pm **Posts:** 8

max wrote:

are you 100% sure you are not processing more than one schema with the same table name used twice ?

if not I would like to get a minimal testcase for it in jira.

Actually, I'm pretty sure that it WAS processing more than one schema with the same table name. Unfortunately, I couldn't figure out how to get it to process only one schema. It seemed to ignore any filtering I had specifying the schema I wanted it to process. As a workaround, I just specified a pattern for the tables that I wanted. I would still like to know how to limit it to a single schema, however.

max · **Posted:** Tue Mar 20, 2007 10:20 am

in 9b the easiest is to just set default_schema to the schema name.

later versions (svn) has fixed our bug with respect to schema-filters.

WallyHartshorn · **Joined:** Tue Feb 20, 2007 4:14 pm **Posts:** 8

max wrote:

in 9b the easiest is to just set default_schema to the schema name.

later versions (svn) has fixed our bug with respect to schema-filters.

Ah! A bug! Well that would explain it. I seem to be (un)lucky when it comes to hitting bugs that a fixed in the next version. :-) Okay, thanks for the info!