kyters / jlibs

Automatically exported from code.google.com/p/jlibs
1 stars 0 forks source link

Support for non-standard database types #17

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?

1. Use of database-specific types

What is the expected output? What do you see instead?

 The jlibs/jdbc API provides no way to pass type information down with parameters to its setObject calls (e.g. in JDBC.setParams). For some non-standard database types, it's necessary to pass the type as java.sql.Types.OTHER.

What version of the product are you using? On what operating system?

 Latest SVN version; Windows & Linux.

Please provide any additional information below.

 It's not possible to use the @TypeMapper "mapsTo" type value for this, because the type within Java for all other purposes may be something like String, but the mapping in the database isn't to varchar (or text or cblob or ...).  And the situation can happen without even needing a TypeMapper, as the data may otherwise be treated like it was just a String (or some other class which already has default mappings).

 Either @Column(overrideSqlType=[some java.sql.Types]) or @OverrideSQLType([some java.sql.Types]) would make sense.  At this point I don't know of a case where a value other than "OTHER" needs to be used, but it would be good to allow the user to pass any Types value they need.

Original issue reported on code.google.com by eire...@gmail.com on 2 Jun 2011 at 4:08

GoogleCodeExporter commented 9 years ago
I put together an implementation for this.  This seems to work well with my 
data that is using non-standard data types.  I tried a couple variations, but 
the alternatives either were not as type-safe or required adding a "default" 
value to the SQLType enum, which could have side-effects elsewhere.

This simply adds support for @OverrideSQLType(jlibs.jdbc.SQLType.XXXX), and 
when present, wraps values in a type (i.e. TypedValue) that setParams later 
detects and unwraps.

No changes were needed to the existing custom SQL methods, but if a user needs 
to, they can use the same wrapper to force the typing on individual arguments:

 EMPLOYEES.update("set age=? where custom_typed_name=?",
                  25, new TypedValue(SQLType.OTHER, "kumar"));

Original comment by eire...@gmail.com on 4 Jun 2011 at 4:24

Attachments:

GoogleCodeExporter commented 9 years ago
FIXED@r1526

set nativeType=true on Column Annotation

Original comment by santhosh.tekuri@gmail.com on 10 Jun 2011 at 4:31