Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 84565 invoked from network); 30 Apr 2007 19:04:11 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 30 Apr 2007 19:04:11 -0000 Received: (qmail 42974 invoked by uid 500); 30 Apr 2007 19:04:18 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 42756 invoked by uid 500); 30 Apr 2007 19:04:17 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 42747 invoked by uid 99); 30 Apr 2007 19:04:17 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 30 Apr 2007 12:04:17 -0700 X-ASF-Spam-Status: No, hits=2.9 required=10.0 tests=HTML_10_20,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of msatoor@gmail.com designates 209.85.132.241 as permitted sender) Received: from [209.85.132.241] (HELO an-out-0708.google.com) (209.85.132.241) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 30 Apr 2007 12:04:10 -0700 Received: by an-out-0708.google.com with SMTP id c25so1309343ana for ; Mon, 30 Apr 2007 12:03:49 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=p+Yv4EIjtbyf8P+2gYYTjhOTowO9UPQYR8HN/U8AB/jcMHWvRZz75WNlcWWFYGDJpEgPqg+8y80sRjmLuIVJZ9QJ9eACirwAkczgeP/i0ntKT8heGIdPYw5d0HvV0Mj5IAS1Y0W3Z0sTXCVE4P2pdr2mOoHFCuwSY3XpzAkfNuQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=SccANxZI2uuuJRktOYOMygtd2dTjE4KZT+B6gaylqjZJLjp9oi585VJVQljs0ZKIWt2Is3UF3J19r4VX4Ws7QtdQStCQFcWwGdakiyPPZ86lhZUTpJQqBQusVDKN0ZrGGUn4Pwi3KnI3pqfMQr7IirmHWWRwOq1NdpGwg7SAVJA= Received: by 10.100.42.7 with SMTP id p7mr4391294anp.1177959829361; Mon, 30 Apr 2007 12:03:49 -0700 (PDT) Received: by 10.100.189.9 with HTTP; Mon, 30 Apr 2007 12:03:49 -0700 (PDT) Message-ID: Date: Mon, 30 Apr 2007 12:03:49 -0700 From: "Mamta Satoor" To: derby-dev@db.apache.org Subject: Re: DERBY-1478 Lineitem DERBY-2599: Associating correct collation type and derivation with DTD In-Reply-To: <463633CE.8030404@apache.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_53854_18214704.1177959829274" References: <463633CE.8030404@apache.org> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_53854_18214704.1177959829274 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Currently, TypeDescriptorImpl has collation derivation of "implicit". I was thinking that although it does not apply to non-collation sensitive datatypes, it should be set to "none", but maybe it doesn't matter because for non-collation sensitive datatypes, noone should worry about collation derivation. So, if we decide on having collation type of "implicit" for non-collation sensitive datatypes, then I guess we don't need to worry about collation settings when such DTDs get created. Also, Dan, I am assuming when you say setCollation(), you mean setCollationType and setCollationDerivation methods on DTD. If we do want to rely on those 2 methods rather than the DTD constructor, then I am thinking that we should default the collation type to be UCS_BASIC on TypeDescriptorImpl (right now, it is not initialized to anything). That way, only character types with a possibility of TERRITORY_BASED/UCS_BASIC collation will call setCollationType. But places like DataDictionaryImpl.create_SYSCS_procedures, where we known collation type can only be UCS_BASIC will not have to call setCollationType. If this sounds fine, i will start looking at using setCollationType method vs constructor. Mamta On 4/30/07, Daniel John Debrunner wrote: > > Mamta Satoor wrote: > > Hi, > > > > I am working on putting the correct collation type and derivation for > > DTDs. The approach I am taking is to change all the constructors for > > DTDs to accept the collation type and derivation. It will be the > > responsibility of the caller of the DTD constructor to pass this > > information for all different kinds of DTDs, ie whether the DTD is for > > collation sensitive datatypes (which include the character string > > datatypes), or all the other non-collation sensitive datatypes (eg > > numeric, binary etc,). For non collation sensitive datatypes, the caller > > will pass collation derivation of "none" which will mean that collation > > type of such datatypes should be ignored. > > > > I just wanted to bring it to community's attention that this approach of > > changing the DTD constructor signature is requiring lot of changes since > > all the callers now have to taken on the task of passing the collation > > type and derivation. I think that is the right approach ie have callers > > take on the responsibility of associating the collation types and > > derivations for their DTDs. Let me know if anyone has any feedback on > > how I am approaching this. > > Why not just a setCollation() method? > > Dan. > > ------=_Part_53854_18214704.1177959829274 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Currently, TypeDescriptorImpl has collation derivation of "implicit". I was thinking that although it does not apply to non-collation sensitive datatypes, it should be set to "none", but maybe it doesn't matter because for non-collation sensitive datatypes, noone should worry about collation derivation. So, if we decide on having collation type of "implicit" for non-collation sensitive datatypes, then I guess we don't need to worry about collation settings when such DTDs get created.
 
Also, Dan, I am assuming when you say setCollation(), you mean setCollationType and setCollationDerivation methods on DTD. If we do want to rely on those 2 methods rather than the DTD constructor, then I am thinking that we should default the collation type to be UCS_BASIC on TypeDescriptorImpl (right now, it is not initialized to anything). That way, only character types with a possibility of TERRITORY_BASED/UCS_BASIC collation will call setCollationType. But places like DataDictionaryImpl.create_SYSCS_procedures, where we known collation type can only be UCS_BASIC will not have to call setCollationType.
 
If this sounds fine, i will start looking at using setCollationType method vs constructor.
 
Mamta
 
On 4/30/07, Daniel John Debrunner <djd@apache.org> wrote:
Mamta Satoor wrote:
> Hi,
>
> I am working on putting the correct collation type and derivation for
> DTDs. The approach I am taking is to change all the constructors for
> DTDs to accept the collation type and derivation. It will be the
> responsibility of the caller of the DTD constructor to pass this
> information for all different kinds of DTDs, ie whether the DTD is for
> collation sensitive datatypes (which include the character string
> datatypes), or all the other non-collation sensitive datatypes (eg
> numeric, binary etc,). For non collation sensitive datatypes, the caller
> will pass collation derivation of "none" which will mean that collation
> type of such datatypes should be ignored.
>
> I just wanted to bring it to community's attention that this approach of
> changing the DTD constructor signature is requiring lot of changes since
> all the callers now have to taken on the task of passing the collation
> type and derivation. I think that is the right approach ie have callers
> take on the responsibility of associating the collation types and
> derivations for their DTDs. Let me know if anyone has any feedback on
> how I am approaching this.

Why not just a setCollation() method?

Dan.


------=_Part_53854_18214704.1177959829274--