How can I handle TIMESTAMP(3) columns, since I have it in my Oracle database and hibernate tools can't reverse-engineer them as a TIMESTAMP.

Is it is possible to handle such columns using simple java.util.Timestamp?

I guess it is more feature of the Oracle JDBC driver because it returns OTHER instead of TIMESTAMP but maybe there is some mechanizm to override it.

When I try to map it explicitly to java.utils.TimeStamp it does not allow me ("Sql type mismatch ...").

======= config ========
...
<column name="LOCALAVAILABLETIME" type="java.sql.Timestamp" />
...

======= log ========
...
16:11:24,609 DEBUG OverrideRepository:303 - columnToHibernateTypeName, explicit mapping found: java.sql.Timestamp for Table: FEWS.SYSTEMACTIVITIES column: LOCALAVAILABLETIME
16:11:24,609 DEBUG JDBCBinder:539 - preferredHibernateType: java.sql.Timestamp
6:11:24,609 DEBUG JDBCBinder:550 - Sql type mismatch for Table: FEWS.SYSTEMACTIVITIES column: LOCALAVAILABLETIME between DB and wanted hibernate type. Sql type set to 1111(OTHER) instead of 93(TIMESTAMP)
...


I also tried to put TIMESTAMP(3) into configuration file, but of course it did not work because there is no such jdbc type:

<sql-type jdbc-type="TIMESTAMP(3)" hibernate-type="java.utils.Timestamp" />

However JDBCReader.java (508) returns "TIMESTAMP(3)":

String sqlTypeName = (String) columnRs.get("TYPE_NAME");

please check out the latest release (i'm going to announce it shortly ;)
and let me know if the problem persists when you specify it explicitly on the column.

If the problem persists, just go ahead and create a jira issue *with* a schema and reveng.xml that fails. Thank you.

I've used latest version from SVN ... it did not compile smoothly when using "ant", because it expected antlr-*.jar and junit-*.jar in my ~/.ant/lib directory ... but this is another issue :).

See http://opensource.atlassian.com/project ... se/HBX-700.

My suggestion is that probably it would be nice if <sql-type> would allow custom TYPE_NAMEs returned by JDBC drivers (like Oracle):

<type-mapping>
<sql-type jdbc-type="TIMESTAMP(3)" hibernate-type="timestamp" />
</type-mapping>

the ant thing is an *ant* thing...tell me how you would make it work ;)

btw. you can use the build.bat which should work.

and using jdbc-type for this would be wrong since it is *not* a jdbc-type and i can't distinguish if a given attribute is one or the other.

anyhow we have an issue somewhere talking about allowing a db-type which would allow you to specify one or the other.

... oh, you're right :), btw is Maven better in this?

It seems that something was fixed recently in Ant if I'm not wrong:
http://issues.apache.org/bugzilla/show_bug.cgi?id=38799

* <junit> can now work with junit.jar in its <classpath>. Bugzilla Report 38799.

However it still not released yet, so for now build.bat or .ant will work fine for me.

----
About jdcb-type - probably it should be something like:

<type-mapping>
<sql-type jdbc-type="OTHER" jdbc-type-name="TIMESTAMP(3)" hibernate-type="Timestamp" />
</type-mapping>

Since they are a bit different, for one jdbc-type you can get several jdbc-type-names.

jdbc-type - DATA_TYPE
jdbc-type-name - TYPE_NAME

Or even better:

<type-mapping>
<sql-type jdbc-type-name="TIMESTAMP(3)" hibernate-type="Timestamp" />
</type-mapping>

----
One more small question, is it possible to tell hibernate-tools to skip schema="<SCHEMA>" in the generated .hbm.xml files? I'm trying to convert data from the DB (Oracle) which supports schemas to some embedded DB (Firebird) which doesn't.

Or even better would be to make SchemaUpdate detect that there are no SCHEMA support. I guess there should be more code in FirebirdDialect.java.
[/quote]

Don't know. hibernate svn can actually be built with no ant installed whatsoever as long as you use build.bat.



set default_schema to the schema part you don't want to have in your generated files.

(i'm btw. thinking of trying to detect if there is only one single schema used in the reverse engineered tables; thus allowing the schema/catalog parts to be excluded automatically (unless default_schema is set to something specific)

Don't know. hibernate svn can actually be built with no ant installed whatsoever as long as you use build.bat.



set default_schema to the schema part you don't want to have in your generated files.

(i'm btw. thinking of trying to detect if there is only one single schema used in the reverse engineered tables; thus allowing the schema/catalog parts to be excluded automatically (unless default_schema is set to something specific)

... it looks a bit implicit for me why it was called *jdbc-type* ;).

I've called it jdbc-<...> since both DATA_TYPE and TYPE_NAME are part of the JDBC spec. returned by the JDBC driver.

In my oppinion it would be more appropriate and obvious to call them in the same way as they are defined in the JDBC spec, e.g. (jdbc-3_0-fr-spec.pdf:142):

<!-- Mapping of standard db types defined in java.sql.Types enum and returned by the JDBC driver as DATA_TYPE, source type can be defined both as int or name defining specific java.sql.Types member-->
<sql-type jdbc-data-type="NUMERIC" hibernate-type="long" />

<!-- Mapping of all other specific types returned by the JDBC driver as TYPE_NAME -->
<sql-type jdbc-type-name="TIMESTAMP(3)" hibernate-type="timestamp" />

again, they are *not* jdbc types, they are *db* specific type names.

It was called jdbc-type because it is the type's defined by the jdbc spec (TIMESTAMP(3) is not part of jdbc spec)

Ok, youre right, after reading a bit more I agree :).

But in this case it is either necessary to invent one more attribute like db-type for db-specific types.
Would it be better to have only db-type and than include all db-specific types and jdbc-standard types into it? (db-type <-> hibernate-type)

have to be different (i think) since a db's name for a type might collide with the jdbc type which might be different!

e.g. jdbc has a notion of TIMESTAMP, but that is not the same as Oracle's TIMESTAMP apparently.

...and the db name also includes precision info etc. which we need to handle somehow (e.g TIMESTAMP(3))

In general it may be assumed that JDBC driver can handle it. For example in my case TIMESTAMP(3) is perfectly handled using java.util.Date.
Of course it worked after hacking JDBCReader and saying that TIMESTAMP(3) is the same as TIMESTAMP :).
It may work at least for simple types.

what do you mean ?

yes, one can always hack the code to specific codes from specific db's;
but that doesn't help me solve the general problem of e.g. oracle's driver mapping alot of sensible and valuable information over to the generic OTHER type.

Yes, it will be not so generic, ... sigh ... Oracle ...

One small issues:

1. is it possible to say hibernate-tools to handle column named "BLOB" as "`BLOB`"?

... it sounds strange to call column in the same way as type but I can't change that field names in the original DB :((

2. Is it possible to change precision of the column, e.g.:

NUMERIC(22) => big_decimal(18)