Mailing-List: contact users-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@openjpa.apache.org
Received-SPF: pass (athena.apache.org: local policy)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII; delsp=yes; format=flowed
Date: Fri, 08 Jan 2010 11:34:04 -0800
From: Craig L Russell <Craig.Russell@Sun.COM>
Subject: Re: Multibyte characters on SQL Server and Sybase
In-reply-to: <1262977233863-4274294.post@n2.nabble.com>
Sender: Craig.Russell@Sun.COM
To: users@openjpa.apache.org
Message-id: <3A42CAD2-E524-4C78-95DF-40A857995480@SUN.com>
References: 
 <OF7A2C71FD.2E891AA0-ON852576A5.004F32A9-852576A5.0057477E@ca.ibm.com>
 <AE98DC86-DEEC-4536-BFED-C5D03FF15202@SUN.com>
 <1262977233863-4274294.post@n2.nabble.com>


On Jan 8, 2010, at 11:00 AM, Marc.Boudreau wrote:

>
> No, the problem is that code can be run on a variety of database  
> platforms
> like DB2, SQL Server, Oracle, etc...
> So if I use @Column(columnDefinition="NVARCHAR(256)"), it will only  
> work on
> SQL Server and Sybase, because the other database platforms don't  
> recognize
> the NVARCHAR type.

I see. How about having the DataDictionary process the  
columnDefinition in a database-specific way? IIRC, all of the  
databases support national use character set columns but in their own  
way.

The columnDefinition is not further standardized in the specification  
so we can do anything we want to with it.

We could analyze the columnDefinition and look for the ANSI standard  
strings NCHAR(n) and NVARCHAR(n) and translate these into the database- 
specific type.

Craig
>
>
> Craig L Russell wrote:
>>
>> Hi,
>>
>> On Jan 8, 2010, at 7:53 AM, Marc Boudreau wrote:
>>
>>>
>>>
>>> Currently, OpenJPA maps String fields to VARCHAR on SQLServer and
>>> Sybase.
>>> There doesn't appear to be a way to cause a String field to be
>>> mapped to
>>> NVARCHAR other than by using the @Column annotation and settings its
>>> columnDefinition to "NVARCHAR".
>>
>> What is the objection to using this technique on the columns that you
>> want to hold national use characters? It seems this use case is
>> exactly suited to this feature.
>>
>>> At the same time, blindly using NVARCHAR
>>> for all String fields is too costly in terms of storage space on the
>>> database.  It ends up limiting the maximum size of the column (less
>>> characters can fit because more bytes are used to store them).
>>>
>>> Unfortunately, the applications we write are required to be database
>>> neutral because we support multiple vendors.
>>>
>>> I'd like to start a discussion on this matter.  Here are a couple of
>>> points
>>> to lead us off...
>>>  What's the severity of this missing functionality?
>>>  Could an OpenJPA specific annotation be introduced to allow the
>>> mapping
>>>  tool to use NVARCHAR instead of VARCHAR?.
>>
>> Is the problem that the OpenJPA mapping tool doesn't support the
>> standard columnDefinition annotation in the way you want it to?
>>
>> Craig
>>
>>>
>>>
>>>
>>> Marc Boudreau
>>> Software Developer
>>> IBM Cognos Content Manager
>>> marc.boudreau@ca.ibm.com
>>> Phone: 613-356-6412
>>
>> Craig L Russell
>> Architect, Sun Java Enterprise System http://db.apache.org/jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>>
>>
>
> -- 
> View this message in context: http://n2.nabble.com/Multibyte-characters-on-SQL-Server-and-Sybase-tp4274154p4274294.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.

Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!