Re: [jira] Commented: (OPENJPA-221) DerbyDictionary doesn't describe a working mapping for char fields.

[Craig L Russell]

First, let me observe that Java char is a single entity that represents one of 65535 or so different items, more if you are trying to represent characters in Chinese that require Unicode-4 byte representation.

Craig

On Apr 18, 2007, at 3:37 PM, Patrick Linskey wrote:

Most databases treat CHAR(1) as a single byte, which is great for ASCII 8 but woefully inadequate for representing Java char. 1. For the best accuracy in all databases, mapping char to String.valueOf((int)char) is bound to be correct. 2. But if the user wants to lose precision and save a few bytes in the database, mapping directly from char to CHAR(1) is ideal. It doesn't seem to me that there is a single "best" solution to this issue. Historically, Kodo mapped char to INTEGER or VARCHAR column types and there is nothing intrinsically wrong with this. On the other hand, if the column type is CHAR(1) there is no way to represent any of the ASCII characters 0-9;a-z;A-Z so there is something to be said for assuming a different mapping in this case. I don't know how feasible it is, but maybe if openjpa can detect that the column used to store a char is defined as SQL CHAR(1) then the mapping to the database character is used. And we can then depend on the database to signal that it's unhappy with storing a char that doesn't fit.

Does that mean you store Strings as arrays of integers by
default for the same reason?

No.

Why is this different?

Because we've regularly run into problems with chars, and have found
that mapping them as ints by default gets around the problems.

There aren't any non-incubator openjpa releases yet, so I
don't see the problem.

Any other opinions?

I'd also expect that for preexisting
tables either an INTEGER or CHAR column would work.

They do, as long as you configure things correctly.

openjpa.Log: SQL=TRACE

Where would I put this so I could see what the unit tests were doing?

What are "the unit tests"? Your tests, or the tests in the OpenJPA
project?

For your tests, add a <property name="openjpa.Log" value="SQL=TRACE"/>
to your persistence unit. See

http://incubator.apache.org/openjpa/docs/latest/manual/ manual.html#ref_g

uide_logging.

(1) is a lot more important, but changing the answer to (2)
is easier and solves my immediate problem.

I don't think that 1 is important, since you can trivially set
storeCharsAsNumbers to true. Ditto for 2.

-Patrick

--
Patrick Linskey
BEA Systems, Inc.

by email and then delete it.

______________________________________________________________________ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this

-----Original Message-----
From: David Jencks [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 18, 2007 3:20 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: [jira] Commented: (OPENJPA-221) DerbyDictionary
doesn't describe a working mapping for char fields.


On Apr 18, 2007, at 11:12 AM, Patrick Linskey wrote:

Hi,

IIUC derby is a pure java db optimized for use with java

and storing

java primitive types basically using java serialization.

Why would

openjpa want to store a char in derby as an integer?

"Because we've always done it that way." Is there a reason why we
should not be storing chars as numbers? Historically, we've seen
problems with comparisons and localization issues when

storing chars

as chars, which is why we store them as ints by default.

Does that mean you store Strings as arrays of integers by
default for the same reason?  Why is this different?

Based on the fact that you said
that the unit tests fail with Derby with that configuration

change, it

sounds like there are some sorts of issues with char mappings in
Derby.

The unit tests fail with only the storeCharsAsIntegers=false
because the sql for creating the table is invalid.  They
succeed with the additional patch to create a CHAR(1) column
instead of CHAR(255) for a char field.  I'm happy to discuss
if creating a  CHAR(255) column to store a char field is
reasonable :-)

Additionally, since we've always done it that way, changing

would mean

backwards-compatibility problems.

There aren't any non-incubator openjpa releases yet, so I
don't see the problem.  I'd also expect that for preexisting
tables either an INTEGER or CHAR column would work.

Why are the current settings correct, despite not working with the
obvious char <> CHAR mapping?

How do you define "not working"? It's my expectation that if the
application behaves as expected, then things are working. It sounds
like what you're saying is "the default is not what was

expected", not

that "things don't work".

I expect that if I have a char field in an object and a
preexisting table with a CHAR column openjpa will figure out
some way to get a char from the field to the column and back
again without any additional configuration, for all
databases.  Admittedly my proposed fix only does this for
derby, and by changing the default mapping for chars for derby.

I additionally expect that if openjpa creates a schema for me
for a database with default utf support it will map a char
field to a CHAR column.  I wouldn't necessarily expect this
for a database that by default doesn't have utf columns.

I haven't found the magic setting so I can see what table is being
created for the unit tests

openjpa.Log: SQL=TRACE

Where would I put this so I could see what the unit tests were doing?

I think there are 2 issues here:

1. should openjpa be able to use a preexisting CHAR column

2. should the settings for derby be storeCharsAsInteger =
false or true?

(1) is a lot more important, but changing the answer to (2)
is easier and solves my immediate problem.

thanks
david jencks

for storing a char, no matter what the storeCharsAsInteger setting is?

-Patrick

--
Patrick Linskey
BEA Systems, Inc.

_____________________________________________________________________ _

_
Notice:  This email message, together with any attachments, may
contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and
affiliated
entities,  that may be confidential,  proprietary,  copyrighted
and/or
legally privileged, and is intended solely for the use of the
individual or entity named in this message. If you are not the
intended recipient, and have received this message in error, please
immediately return this by email and then delete it.

-----Original Message-----
From: David Jencks [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 18, 2007 10:53 AM
To: open-jpa-dev@incubator.apache.org
Subject: Re: [jira] Commented: (OPENJPA-221)

DerbyDictionary doesn't

describe a working mapping for char fields.

I'm not understanding something, maybe someone could explain, and
obviously the comments I suggested in DBDictionary are completely
wrong, although I sure don't see why.

IIUC derby is a pure java db optimized for use with java

and storing

java primitive types basically using java serialization.

Why would

openjpa want to store a char in derby as an integer?  Why are the
current settings correct, despite not working with the

obvious char

<> CHAR mapping?  I haven't found the magic setting so I

can see what

table is being created for the unit tests, but I'm pretty sure it
isn't creating a CHAR column for the char field in the allTypes
object.

I assumed the problems I ran into were a result of no one having
tested this code path, but you appear to be saying that

the current

code is more correct than my proposal.  I'd really like to

know why.

On Apr 18, 2007, at 10:18 AM, Patrick Linskey (JIRA) wrote:

    [ https://issues.apache.org/jira/browse/OPENJPA-221?
page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
tabpanel#action_12489820 ]

Patrick Linskey commented on OPENJPA-221:
-----------------------------------------

It's not surprising that the OpenJPA tests

storeCharsAsNumbers to be

true.

maybe to you :-)  I still find it extremely surprising, and can't
imagine any reason why you'd want to do this.

I was referring to your test environment. Rather than

changing the

default behavior of the DerbyDictionary in code, it seems more
appropriate to use the built-in configuration option to

toggle it for

your application.

It sounds like you're reluctant to do this since you don't

have easy

access to modify the persistence.xml files. Happily, if

you drop a

file conforming to the persistence.xml schema into META-INF/
openjpa.xml, OpenJPA will load the settings in the

properties in the

first PU in that file as defaults for all PUs.

What happens if you put the DBDictionary stanza that I mentioned
earlier into a META-INF/openjpa.xml file?

Won't this change the behavior for all databases, not just

the derby

dictionary?  I'd prefer to

(a) understand why these settings as are they are
(b) make all the db-specific dictionaries work unmodified with all
reasonable mappings.

thanks
david jencks

DerbyDictionary doesn't describe a working mapping for

char fields.

-------------------------------------------------------------------

                Key: OPENJPA-221
                URL: https://issues.apache.org/jira/browse/
OPENJPA-221
            Project: OpenJPA
         Issue Type: Bug
         Components: sql
   Affects Versions: 0.9.7
           Reporter: David Jencks
        Attachments: OPENJPA-221.patch


If a class has a char field mapped to CHAR or CHAR(1) in a derby
database, the derby dictionary sets up a mapping to an

integer column

which doesn't work.  openjpa tries to store e.g. the

string "97" for

the char 'a' which results in a truncation error.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Notice:  This email message, together with any attachments, may
contain information  of  BEA Systems,  Inc.,  its subsidiaries
and  affiliated entities,  that may be confidential,

proprietary,

copyrighted  and/or legally privileged, and is intended

solely for the

use of the individual or entity named in this message. If

you are not

the intended recipient, and have received this message in error,
please immediately return this by email and then delete it.

Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature