Hi,

Im just having an issue with reverse engineering an existing db schema.

(Just after fixing part of the issue there)
Basically, when you want to use a table filter to include a set of tables using a wildcard but exclude tables within that subset, you HAVE TO have the exclude defined before the include such as :

<table-filter match-name="LA_ERRORMESSAGES" match-schema="LA" exclude="true"/>
<table-filter match-name="LA_.*"/>

If you have it the other way around, then it will include the above table. I think this could be better documented as it is not very obvious.


Also, it does not seem to pick up my particular type mappings. Basically, i don't want any primitive longs, ints etc in the application, i want to use the java.lang.Long instead. It doesn't do this for me, it keeps using a primitive. Can anyone see what i am doing wrong?

Thanks a lot for any help,
John

Hibernate version: 3.2.4.sp1

Mapping documents:

<?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="LA"/>

<type-mapping>

<sql-type jdbc-type="NUMERIC" precision="15" hibernate-type="big_decimal"/>
<sql-type jdbc-type="NUMERIC" hibernate-type="java.lang.Long" />
<sql-type jdbc-type="VARCHAR" length="1" hibernate-type="java.lang.Character"/>
<sql-type jdbc-type="VARCHAR" hibernate-type="string"/>

</type-mapping>

<table-filter match-name="LA_ERRORMESSAGES" match-schema="LA" exclude="true"/>
<table-filter match-name="LA_.*"/>

</hibernate-reverse-engineering>

Name and version of the database you are using: Oracle 10g

regarding ordering then we could probably point it out, but the rules are simple: "First hit wins"

You don't show what it actually generates so can't see what type is actually matched...

DB Column Type Details:
Type : NUMERIC
Length : 10
Scale : 0
Not Null : True
Default : None

Reveng Type Details:
<type-mapping>

<sql-type jdbc-type="NUMERIC" precision="15" hibernate-type="big_decimal"/>
<sql-type jdbc-type="NUMERIC" hibernate-type="java.lang.Long" />
<sql-type jdbc-type="VARCHAR" length="1" hibernate-type="java.lang.Character"/>
<sql-type jdbc-type="VARCHAR" hibernate-type="string"/>

</type-mapping>

Mapped Document Type Details:
<property name="dlwcAccountId" type="long">
<column name="DLWC_ACCOUNT_ID" precision="10" scale="0" not-null="true" unique="true" />
</property>

Thanks,
John

it says not-null=true, then it can't be a Long.

if you put not-null=true in the type-mapping it should "force it"

Yeah i had tried that previously alright but it doesn't seem to work for me.

Produced the following:

<property name="dlwcAccountId" type="long">
<column name="DLWC_ACCOUNT_ID" not-null="true" precision="10" scale="0"/>
</property>

after updating rev eng file:
<type-mapping>

<sql-type jdbc-type="NUMERIC" precision="15" hibernate-type="big_decimal"/>
<sql-type jdbc-type="NUMERIC" not-null="true" hibernate-type="java.lang.Long" />
<sql-type jdbc-type="VARCHAR" length="1" hibernate-type="java.lang.Character"/>
<sql-type jdbc-type="VARCHAR" hibernate-type="string"/>

</type-mapping>

are you 100% sure that this column actually returns java.sql.Types.NUMERIC when the db is asked for the column type via jdbc metadata ?

db.NUMERIC not necessarily equal to java.sql.Types.NUMERIC

Looks like it is returning it's type as a BigDecimal, yet it puts long in mapping file:


SQL:

SELECT ll.dlwc_account_id from la_licenses ll where ll.license = 'example'

Java Code after query is executed:
ResultSetMetaData meta = rset.getMetaData();
for(int i = 1; i <= meta.getColumnCount(); i++){
System.out.println("colClass=["+meta.getColumnClassName(i)+"]");
System.out.println("colType=["+meta.getColumnType(i)+"]");
System.out.println("colTypeName=["+meta.getColumnTypeName(i)+"]");
}

Logging:

colClass=[java.math.BigDecimal]
colType=[2]
colTypeName=[NUMBER]


Dont worry about this too much as it is not absolutely essential to me.
Thanks

the type is NUMBER, not NUMERIC then.

thanks for that.