Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-dev] Support for national character types
Since no one had any comments about this approach I'm going to dive in tomorrow.

On Wed, Jan 21, 2015 at 4:50 PM, Rick Curtis <curtisr7@xxxxxxxxx> wrote:
Finally getting back to this issue. 

I talked some more with one of my stake holders and discussed wants / vs needs in regards to national character support. We broke this problem down into two separate issues. The first and most important is table creation. They need a generic way to tell the EclipseLink runtime to create String columns as a type that will support national character types (a la unicode). Since they are writing code that will run against any number of databases, it isn't a viable option to specify this information in a @Column annotation (or xml). Unfortunately support for unicode column types isn't fully standard across the range of supported databases. For example, to be able to store the following Java String "\u215c" each database needs to have a column defined in this way:
Oracle: NVARCHAR2

DB2: VARCHAR
Derby: VARCHAR

MySQL: NVARCHAR
Informix: NVARCHAR
Sybase: NVARCHAR
SQLServer: NVARCHAR

This is problem #1 and can be mostly implemented by way of a new property that can be set on the DatabasePlatform to change how Strings are mapped and each Platform will need to be updated. This only addresses the problem from a table creation point of view.

Problem #2 is more involved and entails adding runtime support for JDBC 4.0 setN, etc methods. For the sake of keeping a targeted discussion, I'm going to table issue #2 till the future when myself/others have more time to add full jdbc4.0 support.

Without a proper solution for #2, we still have something workable by relying on each JDBC driver to handle unicode values for us. Nearly all of the databases mentioned have some way to configure the driver to properly handle unicode values. Example:

Oracle: jvm property -Doracle.jdbc.defaultNChar=true
Derby: none
MySQL: jdbc connection property characterEncoding=utf8
SQLServer: jdbc connection property (default) sendStringParametersAsUnicode=true
Informix: unknown
Sybase: unknown
DB2: none

Woa, sorry for the wall of text here... hopefully I didn't scare everyone away. Long story short, I need to add support to the runtime to generically specify that I want all Strings to be mapped to a unicode supporting type.

Thoughts?

Rick

On Wed, Jan 7, 2015 at 8:59 AM, andrei ilitchev <andrei.ilitchev@xxxxxxxxxx> wrote:
Take a look at NCharacter, NString, NClob support for Oracle db in org.eclipse.persistence.oracle

On 1/6/2015 5:46 PM, Rick Curtis wrote:
I've been given the requirement that some users need the ability to tell EclipseLink to treat all Strings as NVARCHAR type rather than VARCHAR. I did a bit of searching around and haven't found much discussion regarding this issue. I know with some jdbc drivers I can rely on some pre jdbc-4.1 workarounds (sqlserver SendStringParametersAsUnicode), but I'd prefer to stay away from those. 

I'm wondering if anyone has a feeling for how large of a change this will be?

After thinking through this I came up with the following :

* Configuration option that is something like 'use national types for Strings'... obviously this is platform dependent. Ideally a future version of the spec will add an attribute to the @Basic type to denote that a given field needs to use national character types.
* Updates to the runtime to use proper ResultSet.get/PreparedStatement.set methods for NCHAR,
NVARCHAR, LONGNVARCHAR, and NCLOB. -- jdbc 4.1 requirement
* Updates to the runtime so that table creation uses the national types.
* SQL literals for NCHAR,NVARCHAR,LONGNVARCHAR need a 'N' prefix to the String... that being said I don't think this is an issue because it appears that we (nearly?) always convert JPQL literals to SQL parameters.

Thoughts?

--
Rick Curtis


_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev


_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev



--
Rick Curtis



--
Rick Curtis

Back to the top