Return-Path: X-Original-To: apmail-openjpa-users-archive@minotaur.apache.org Delivered-To: apmail-openjpa-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 28EB8174F6 for ; Tue, 31 Mar 2015 13:55:57 +0000 (UTC) Received: (qmail 4812 invoked by uid 500); 31 Mar 2015 13:55:22 -0000 Delivered-To: apmail-openjpa-users-archive@openjpa.apache.org Received: (qmail 4774 invoked by uid 500); 31 Mar 2015 13:55:22 -0000 Mailing-List: contact users-help@openjpa.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@openjpa.apache.org Delivered-To: mailing list users@openjpa.apache.org Received: (qmail 4763 invoked by uid 99); 31 Mar 2015 13:55:22 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 31 Mar 2015 13:55:22 +0000 X-ASF-Spam-Status: No, hits=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of hal.hildebrand@me.com designates 17.158.236.236 as permitted sender) Received: from [17.158.236.236] (HELO nk11p04mm-asmtp001.mac.com) (17.158.236.236) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 31 Mar 2015 13:55:17 +0000 Received: from [10.0.1.65] (c-69-181-28-87.hsd1.ca.comcast.net [69.181.28.87]) by nk11p04mm-asmtp001.mac.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NM2009DRXB3NZ10@nk11p04mm-asmtp001.mac.com> for users@openjpa.apache.org; Tue, 31 Mar 2015 13:54:40 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-03-31_04:2015-03-31,2015-03-31,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1503310125 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: OpenJPA PostgreSQL UUID column From: Hal Hildebrand In-reply-to: Date: Tue, 31 Mar 2015 06:54:39 -0700 Content-transfer-encoding: quoted-printable Message-id: <88FB0025-44D8-4222-9117-34CEB8C7ADFE@me.com> References: <3ED0768D-B0A2-4BFC-89B2-5EC26E68C3DF@me.com> To: users@openjpa.apache.org X-Mailer: Apple Mail (2.2070.6) X-Virus-Checked: Checked by ClamAV on apache.org Thanks. It=E2=80=99s a bit weird, but I=E2=80=99ll figure it out = eventually. And will definitely update and contribute what I find. -Hal > On Mar 31, 2015, at 6:51 AM, Kevin Sutter wrote: >=20 > Hi Hal, > You said you've been googling this problem, so my suggestions might = have > already been tried (and failed)... >=20 > The use of a ValueHandler sounds like the proper approach for = supporting > the native UUID type. OpenJPA provides a couple of ValueHandlers for > normal use and for test purposes. Have you tried running the = associated > junits to see how the current ValueHandlers are used? That's how I = would > debug this problem. Look at the processing that currently works and = then > compare that to the path that is not working. >=20 > Since ValueHandlers are verified by OpenJPA's test bucket, I would = guess > there is some slight issue with your specific UuidValueHandler. I = took a > quick look, but nothing jumped out at me. Other than your = toDataStoreValue > and toObjectValue look a little light. But, maybe you are just trying = to > get the basic flow to work first? >=20 > Based on this exercise, if you find something that should be beefed up = in > the OpenJPA test suite, please do offer to contribute your findings. >=20 > Thanks, Kevin >=20 > On Fri, Mar 27, 2015 at 6:28 PM, Hal Hildebrand = > wrote: >=20 >>=20 >>=20 >> I=E2=80=99m trying to use the native UUID type for PostgreSQL in my = OpenJPA >> model. I=E2=80=99m using OpenJPA 2.3.0 and at the current level of = the PostgreSQL >> JDBC driver. >>=20 >> I=E2=80=99ve tried to accomplish this several times and I=E2=80=99ve = gotten a bit further >> this time. I created a ValueHolder (see attached file) and it does = what I >> believe is the correct setup for this type. I use this as the = strategy for >> the column - i.e. : >>=20 >> @Strategy("com.chiralbehaviors.CoRE.openjpa.UuidValueHandler") >>=20 >> I=E2=80=99ve validated via breakpoint that the UuidValueHolder is = indeed called in >> setup and when converting values. I=E2=80=99m at the point of trying = to do an >> insert, and regardless of whether I use an actual UUID as the return >> mapping (i.e. no transform) or a string (UUID.toString()) I get the = same >> error: >>=20 >> ERROR: column "id" is of type uuid but expression is of type bytea >> Hint: You will need to rewrite or cast the expression. >> Position: 93 {prepstmnt 1848199707 >> INSERT INTO ruleform.agency (id, notes, update_date, description, = name, >> updated_by) >> VALUES (?, ?, ?, ?, ?, ?) >> [params=3D(byte[]) [B@9ac8b5b, (null) null, (Timestamp) 2015-03-27 >> 15:20:05.921, (null) null, (String) CoRE, (byte[]) [B@15b17c95]} = [code=3D0, >> state=3D42804] >>=20 >>=20 >> I believe that this error comes from the postgres jdbc driver, not >> openJPA. I=E2=80=99ve even tried using PGObject, which surprisingly = works just >> fine, but throws the same error. >>=20 >> In my google searches, this has come across as a typical problem, and = I=E2=80=99ve >> only found solutions for this (hypothesized) for Toplink and = Hibernate. >> The one thing I could find suggested writing the ValueHolder and that = does >> work up until the point I try to actually insert in JDBC land. >>=20 >> Note that the UUID is being passed as a byte array. >>=20 >> So my question is, am I doing anything incorrect? Missing something? >> =46rom the error message, it would appear postgresql wants me to cast = the >> result, but I=E2=80=99m not sure how to accomplish that in OpenJPA. = It could >> simply be a red herring. >>=20 >> Any help appreciated, as I simply can=E2=80=99t find a working = solution via Der >> Google >>=20 >> -Hal >>=20 >>=20