Return-Path: 
 <derby-dev-return-40026-apmail-db-derby-dev-archive=db.apache.org@db.apache.org>
Delivered-To: apmail-db-derby-dev-archive@www.apache.org
Received: (qmail 16724 invoked from network); 3 Apr 2007 23:32:07 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 3 Apr 2007 23:32:07 -0000
Received: (qmail 64978 invoked by uid 500); 3 Apr 2007 23:32:14 -0000
Delivered-To: apmail-db-derby-dev-archive@db.apache.org
Received: (qmail 64937 invoked by uid 500); 3 Apr 2007 23:32:14 -0000
Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:derby-dev-help@db.apache.org>
List-Unsubscribe: <mailto:derby-dev-unsubscribe@db.apache.org>
List-Post: <mailto:derby-dev@db.apache.org>
List-Id: <derby-dev.db.apache.org>
Reply-To: <derby-dev@db.apache.org>
Delivered-To: mailing list derby-dev@db.apache.org
Received: (qmail 64926 invoked by uid 99); 3 Apr 2007 23:32:14 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Apr 2007 16:32:14 -0700
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Received: from [32.97.182.146] (HELO e6.ny.us.ibm.com) (32.97.182.146)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Apr 2007 16:32:06 -0700
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236])
	by e6.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l33NWTuR011267
	for <derby-dev@db.apache.org>; Tue, 3 Apr 2007 19:32:29 -0400
Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217])
	by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id
 l33NViEt293664
	for <derby-dev@db.apache.org>; Tue, 3 Apr 2007 19:31:44 -0400
Received: from d01av03.pok.ibm.com (loopback [127.0.0.1])
	by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l33NViH5013387
	for <derby-dev@db.apache.org>; Tue, 3 Apr 2007 19:31:44 -0400
Received: from [127.0.0.1] (IBM-IKEJ04B1IMA-009072133081.usca.ibm.com
 [9.72.133.81])
	by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id
 l33NVhn5013379
	for <derby-dev@db.apache.org>; Tue, 3 Apr 2007 19:31:43 -0400
Message-ID: <4612E3C2.3050004@sbcglobal.net>
Date: Tue, 03 Apr 2007 16:31:14 -0700
From: Mike Matrigali <mikem_app@sbcglobal.net>
Reply-To: mikem_app@sbcglobal.net
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: some comments on collation wiki page
References: <4611F2C0.2040306@sbcglobal.net>
 <d9619e4a0704030025r71db6239v8e6d0686da6090fb@mail.gmail.com>
 <4612C411.7010904@apache.org> <4612D6A3.7010307@sbcglobal.net>
 <4612DDB8.1010802@sbcglobal.net> <4612E12F.4060106@gmail.com>
In-Reply-To: <4612E12F.4060106@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org



Suresh Thalamati wrote:
> Mike Matrigali wrote:
> 
>>
>> Mike Matrigali wrote:
>>
> <snip>
> 
>>>
>>> Ok, didn't realize this broke the model.  As long as the info gets down
>>> to store I don't really care how.  So if you can't get the info from
>>> the template we pass down, then we should just add another array 
>>> argument to createConglomerate and createAndLoadConglomerate which would
>>> make it look like (this was the approach taken to pass down the 
>>> columnOrdering which is basically ascend/descend info for indexes):
>>>
>>> long createConglomerate(
>>> String                  implementation,
>>> DataValueDescriptor[]   template,
>>> ColumnOrdering[]        columnOrder,
>>> CollationIds[]        collationIds,
>>> Properties              properties,
>>> int                     temporaryFlag)
>>>     throws StandardException;
>>
>>
>>
>>
>> I didn't mean to create a new datatype for the collation id's,
>> I think int or long is fine.
>>
>> long createConglomerate(
>> String                  implementation,
>> DataValueDescriptor[]   template,
>> ColumnOrdering[]        columnOrder,
>> int[]                   collationIds,
>> Properties              properties,
>> int                     temporaryFlag)
>>     throws StandardException;
>>
> 
> Mike ,
> 
> Any particular reason why you don't want add collationIds, to the 
> already existing ColumnOrdering information,  instead of
> passing it as separate int[] array.
That looks like a good idea.  It will take generating a ColumnOrdering 
when we create a heap, where we didn't before but that should not be
too hard.  We use this for sorting also so it does seem like a natural
place for it.
> 
> 
> Thanks
> -suresh
> 
>