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:[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.
