Return-Path: Delivered-To: apmail-db-ddlutils-dev-archive@www.apache.org Received: (qmail 12972 invoked from network); 7 Aug 2006 23:44:37 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 7 Aug 2006 23:44:37 -0000 Received: (qmail 90372 invoked by uid 500); 7 Aug 2006 23:44:37 -0000 Delivered-To: apmail-db-ddlutils-dev-archive@db.apache.org Received: (qmail 90347 invoked by uid 500); 7 Aug 2006 23:44:37 -0000 Mailing-List: contact ddlutils-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: ddlutils-dev@db.apache.org Delivered-To: mailing list ddlutils-dev@db.apache.org Received: (qmail 90336 invoked by uid 99); 7 Aug 2006 23:44:36 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 Aug 2006 16:44:36 -0700 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of tomdzk@gmail.com designates 66.249.92.173 as permitted sender) Received: from [66.249.92.173] (HELO ug-out-1314.google.com) (66.249.92.173) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 Aug 2006 16:44:35 -0700 Received: by ug-out-1314.google.com with SMTP id m2so289080uge for ; Mon, 07 Aug 2006 16:44:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fMH1xONcGCU+h4wwp1QbdXvEJ4aifL3kbrkCNdWemLZ3phvJemqyfJUxHTgnuJvywh9VrvWX2sNS/O9CArtAVhs8AquVnfAcKvcRymSpt8CTGVNi0wwFFrrKE94sD8RU8taSb9cULma5PU6q40WZvMxcxf0DD7gdBAAmM9kVY4Y= Received: by 10.66.244.10 with SMTP id r10mr8826925ugh; Mon, 07 Aug 2006 16:44:13 -0700 (PDT) Received: by 10.67.97.10 with HTTP; Mon, 7 Aug 2006 16:44:13 -0700 (PDT) Message-ID: <224f32340608071644y11a16111ucfaf149562a0551f@mail.gmail.com> Date: Mon, 7 Aug 2006 16:44:13 -0700 From: "Thomas Dudziak" To: ddlutils-dev@db.apache.org Subject: Re: Customisation of jdbc->sql type mapping In-Reply-To: <20060805083452.H90790@minotaur.apache.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060805083452.H90790@minotaur.apache.org> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N On 8/5/06, Thomas Fischer wrote: > Is there any support planned for customisation the mapping from jdbc types > to sql types ? For example, users might want to use nvarchar2 instead of > varchar for some reason. yep, that is one of the core features planned for the 1.1 release. Basically, there are planned to be three levels of customization: - for the Ant task invocation, so that the mapping applies to all schema files handled by this task run - for a schema file - for a specific column the general idea is to have declarative (XML) and programmatic control to e.g. map every occurrence of VARCHAR (JDBC type) to NVARCHAR2 (Oracle type) regardless of length, or also for specific lengths. > In torque, users could do this using the db.props file for the different > databases up to Torque 3.1.1. In Torque 3.2, the db.props file is gone and > it is quite difficult for users to define their own mappings. This needs > to be changed in Torque. However, it would make sense to do this in a > manner that ddlutils might support in the future. > > My current plan for Torque is to use the "domain" attribute in the torque > schema file. A domain (I'm not finding this name intuitive, maybe there's > a better one) is a kind of "custom column type" the user can define. For > example, the user can define a type "SHORTVARCHAR" which corresponds to a > varchar column with size 20. The user then can use the type "shortvarchar" > as column type in the schema, and does not need to specify the size of 20 > everywhere. hmm, this is somewhat different to the above as it basically means that a filter is applied between reading the schema from XML and applying the model (e.g. writing it to the DB). This can surely be done but might perhaps make more sense in a Torque derived XML schema ? I'm not too sure yet, but since it would not be difficult to implement, we can just as well have it in DdlUtils. This would however be different from support DOMAINs in the database as these apply to the native type instead. Tom