Return-Path: X-Original-To: apmail-db-derby-user-archive@www.apache.org Delivered-To: apmail-db-derby-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 98D0A9251 for ; Mon, 14 Nov 2011 13:26:12 +0000 (UTC) Received: (qmail 29945 invoked by uid 500); 14 Nov 2011 13:26:12 -0000 Delivered-To: apmail-db-derby-user-archive@db.apache.org Received: (qmail 29921 invoked by uid 500); 14 Nov 2011 13:26:12 -0000 Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Reply-To: "Derby Discussion" Delivered-To: mailing list derby-user@db.apache.org Received: (qmail 29914 invoked by uid 99); 14 Nov 2011 13:26:12 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 14 Nov 2011 13:26:12 +0000 X-ASF-Spam-Status: No, hits=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS,UNPARSEABLE_RELAY X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [148.87.113.117] (HELO rcsinet15.oracle.com) (148.87.113.117) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 14 Nov 2011 13:26:03 +0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pAEDPfUL026228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 14 Nov 2011 13:25:41 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id pAEDPeMw005166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 14 Nov 2011 13:25:40 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id pAEDPYjG023975 for ; Mon, 14 Nov 2011 07:25:34 -0600 Received: from dhcp-rmdc-twvpn-1-vpnpool-10-159-13-128.vpn.oracle.com (/10.159.13.128) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 14 Nov 2011 05:25:34 -0800 Message-ID: <4EC116CF.9090801@oracle.com> Date: Mon, 14 Nov 2011 05:25:35 -0800 From: Rick Hillegas User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Derby Discussion Subject: Re: UDT and java arrays References: <201111082243.50627.Karl.Weber99@googlemail.com> <201111121136.58213.Karl.Weber99@googlemail.com> In-Reply-To: <201111121136.58213.Karl.Weber99@googlemail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-CT-RefId: str=0001.0A090209.4EC116D5.01F9,ss=1,re=0.000,fgs=0 X-Virus-Checked: Checked by ClamAV on apache.org On 11/12/11 2:36 AM, Karl Weber wrote: > Am Mittwoch, 9. November 2011, 11:51:43 schrieb Knut Anders Hatlen: >> Karl Weber writes: >>> Hi, >>> >>> Derby does support UDTs. One can use any java.io.Serializable java class >>> as a UDT. >>> >>> On the other hand, derby does not support SQL ARRAY types. >>> >>> However, every java array is an object that implements >>> java.io.Serializable, so can one define a UTD of the form >>> >>> CREATE TYPE APP.DARRAY >>> >>> EXTERNAL NAME 'double[]' >>> LANGUAGE JAVA; >>> >>> ? > [...] >>> However, how do I insert values into this table, using normal SQL and >>> using the JDBC API? >> Hi Karl, >> >> The easiest way is to insert values using the JDBC API, like this: >> >> PreparedStatement ps = c.prepareStatement("INSERT INTO XXX VALUES ?"); >> ps.setObject(1, new double[] { 1, 2, 3 }); >> ps.executeUpdate(); >> > Thank you very much, Knut, it works. > > I have one more question: I checked double[], double[][], float[], int[], > short[] and byte[]. Unfortunately the last one does not work: > > IJ Version 10.8 > ij> create type APP.BARRAY >> external name 'byte[]' >> language java; > FEHLER 42Z10: Die an einen benutzerdefinierten Typ gebundene Java-Klasse darf > nicht intern von Derby verwendet werden: 'byte[]'. > ij> > > Why is byte[] not supported? O.k., there is VARCHAR FOR BIT DATA, which maps > to byte[], but it's size is limited to at most 32.672 bytes, a restriction I > do not know of for UDTs. I would need larger byte arrays. The only other way I > know would be to use a BLOB instead.... Anyway, I do not really understand, > why one cannot define a UDT of type byte[]. If I had to use a BLOB: does the > specified length does have any performance or other impact? > Hi Karl, As you noted, byte[] is not an allowed type because it is the backing class for one of Derby's builtin SQL types. You will see the same error if you try to bind a UDT name to java.lang.Integer, which is the backing class for the INT type. Off the top of my head, I don't know what would break if we removed this restriction. For arbitrarily long byte arrays, you can also use LONG VARCHAR FOR BIT DATA. One difference between VARCHAR FOR BIT DATA and the large byte types (BLOB and LONG VARCHAR FOR BIT DATA) is that you can create indexes on VARCHAR FOR BIT DATA. Hope this helps, -Rick