You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "David Jencks (JIRA)" <ji...@apache.org> on 2007/04/18 10:19:15 UTC
[jira] Created: (OPENJPA-221) DerbyDictionary doesn't describe a
working mapping for char fields.
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
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.
RE: [jira] Commented: (OPENJPA-221) DerbyDictionary doesn't describe a working mapping for char fields.
Posted by Patrick Linskey <pl...@bea.com>.
> 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.
Historically, our experience has been that:
1. Users tend to use a single format throughout their database, so a
per-configuration setting is Good Enough.
2. It's generally pretty uncommon to store char fields anyways.
-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: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM]
> Sent: Wednesday, April 18, 2007 6:05 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: [jira] Commented: (OPENJPA-221) DerbyDictionary
> doesn't describe a working mapping for char fields.
>
> 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.
>
> 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.
>
> Craig
>
> On Apr 18, 2007, at 3:37 PM, Patrick Linskey wrote:
>
> >> 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.
> >
> ______________________________________________________________________
> > _
> > 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:david_jencks@yahoo.com]
> >> 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 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:david_jencks@yahoo.com]
> >>>> 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:Craig.Russell@sun.com P.S. A good JDO? O, Gasp!
>
>
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.
Re: [jira] Commented: (OPENJPA-221) DerbyDictionary doesn't describe a
working mapping for char fields.
Posted by Craig L Russell <Cr...@Sun.COM>.
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.
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.
Craig
On Apr 18, 2007, at 3:37 PM, Patrick Linskey wrote:
>> 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.
> ______________________________________________________________________
> _
> 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:david_jencks@yahoo.com]
>> 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
>> 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:david_jencks@yahoo.com]
>>>> 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:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
RE: [jira] Commented: (OPENJPA-221) DerbyDictionary doesn't describe a working mapping for char fields.
Posted by Patrick Linskey <pl...@bea.com>.
> 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.
_______________________________________________________________________
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:david_jencks@yahoo.com]
> 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
> 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:david_jencks@yahoo.com]
> >> 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.
Re: [jira] Commented: (OPENJPA-221) DerbyDictionary doesn't describe a working mapping for char fields.
Posted by David Jencks <da...@yahoo.com>.
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:david_jencks@yahoo.com]
>> 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.
RE: [jira] Commented: (OPENJPA-221) DerbyDictionary doesn't describe a working mapping for char fields.
Posted by Patrick Linskey <pl...@bea.com>.
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. 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.
Additionally, since we've always done it that way, changing would mean
backwards-compatibility problems.
> 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 haven't found the magic setting so I can see what table is
> being created for the unit tests
openjpa.Log: SQL=TRACE
-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:david_jencks@yahoo.com]
> 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.
Re: [jira] Commented: (OPENJPA-221) DerbyDictionary doesn't describe a working mapping for char fields.
Posted by David Jencks <da...@yahoo.com>.
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.
>
[jira] Commented: (OPENJPA-221) DerbyDictionary doesn't describe a
working mapping for char fields.
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ 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.
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?
> 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.
[jira] Commented: (OPENJPA-221) DerbyDictionary doesn't describe a
working mapping for char fields.
Posted by "David Jencks (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489791 ]
David Jencks commented on OPENJPA-221:
--------------------------------------
I'm not in a position to easily modify the applications in question (they are in the tck) but if I only set storeCharsAsNumbers=false in code then I got a lot of openjpa unit test errors complaining that it couldn't create the table for AllFieldTypes, something about CHAR(255). changing the other property fixed that. If I turned off the unit tests then openjpa worked fine with preexisting derby tables with a CHAR column for the char field. Is this enough info?
> 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.
[jira] Updated: (OPENJPA-221) DerbyDictionary doesn't describe a
working mapping for char fields.
Posted by "David Jencks (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Jencks updated OPENJPA-221:
---------------------------------
Attachment: OPENJPA-221.patch
This patch results in a working mapping from a char field to a CHAR column. I also added some comments to the defaults in DBDictionary that I hope are correct and helpful.
> 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.
[jira] Commented: (OPENJPA-221) DerbyDictionary doesn't describe a
working mapping for char fields.
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489761 ]
Patrick Linskey commented on OPENJPA-221:
-----------------------------------------
What happens if, without your patch, you set the DBDictionary 'StoreCharsAsNumbers' property to false?
<persistence>
<persistence-unit name="...">
...
<properties>
<property name="openjpa.jdbc.DBDictionary" value="StoreCharsAsNumbers=false"/>
</properties>
</persistence-unit>
</persistence>
> 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.