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 for
storing a char, no matter what the storeCharsAsInteger setting is?
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
-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.
