Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 17165 invoked from network); 13 Mar 2007 20:52:10 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 13 Mar 2007 20:52:10 -0000 Received: (qmail 68677 invoked by uid 500); 13 Mar 2007 20:52:18 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 68633 invoked by uid 500); 13 Mar 2007 20:52:18 -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 68624 invoked by uid 99); 13 Mar 2007 20:52:18 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 13 Mar 2007 13:52:18 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=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.243 as permitted sender) Received: from [209.85.132.243] (HELO an-out-0708.google.com) (209.85.132.243) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 13 Mar 2007 13:52:07 -0700 Received: by an-out-0708.google.com with SMTP id c25so1738784ana for ; Tue, 13 Mar 2007 13:51:46 -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=e7C2V5M4D65Wsi4I8IqnlIwddiYLNOsHfSNe60fays5oPPiGJo0uhVCop8pnBLKwvTz5eloC21DMWi+IFEFqvmVXGsdFq/Dl6zac+YGEHRNSEWyf86kRETw9wPrHEL4zCgrLffxVSfCfLDTGJsEdF2kE0Z01xI+y+aih+2RNlBI= 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=uXIBo1PBUNxsng9Xu8FdHcCw26pEi9ieUhVuQXQr09IgTFbWNV/4lutulYdbgfVeIeN9+SwRGAmGJK/G4jZsh4Af/evf2b3QwdrVefgeVfIPeU8lwE6rHVOgWXiEugfv4FUeZy5mWricL/m3/bilEu658LlGUYUE3foToQ4qycs= Received: by 10.100.166.14 with SMTP id o14mr1224654ane.1173819106699; Tue, 13 Mar 2007 13:51:46 -0700 (PDT) Received: by 10.100.189.9 with HTTP; Tue, 13 Mar 2007 13:51:46 -0700 (PDT) Message-ID: Date: Tue, 13 Mar 2007 13:51:46 -0700 From: "Mamta Satoor" To: derby-dev@db.apache.org, mikem_app@sbcglobal.net Subject: Re: Comments in StoredFormatIds refer to classes that do not exist. Are these just leftover comments that don't apply anymore? In-Reply-To: <45F6EDD2.1030600@sbcglobal.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_35388_14849484.1173819106648" References: <45F6EDD2.1030600@sbcglobal.net> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_35388_14849484.1173819106648 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Thanks for your time, Mike. Thanks for confirming my thought that these are more than likely just stale comments. Mamta On 3/13/07, Mike Matrigali wrote: > > It is likely that they can be deleted, that they refer to stuff the > predates the derby codeline. I can't think of any persistent datatype > that we got rid of since 10.0. To be absolutely safe one should check > the 10.0 codeline as I can imagine horrible issues with reusing an > existing format id for some on existing on disk datatype (again I don't > remember us getting rid of anything but checking the code is always best > - and note that the class comment is just that - a comment. It could me > that the class was moved without updating the comment. > > > Mamta Satoor wrote: > > Hello, > > > > I was going through iapi.services.io.StoredFormatIds to understand how > > SQLChar is generated by the compiler. I need to understand this in order > > to support generation of SQLChar with their own collator. > > > > In StoredFormatIds, I see several references to classes in the comments > > that don't really exist in Derby. For instance, there is following piece > > of code is StoredFormatIds > > > > /** > > class org.apache.derby.catalog.types.CharTypeIdImpl > > */ > > static public final int CHAR_TYPE_ID_IMPL = > > (MIN_ID_2 + 17); > > > > But there is no CharTypeIdImpl in the catalog.types package. Are these > > comments leftover from the past which should have been fixed? > > > > Thanks, > > Mamta > > ------=_Part_35388_14849484.1173819106648 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Thanks for your time, Mike. Thanks for confirming my thought that these are more than likely just stale comments.
 
Mamta

 
On 3/13/07, Mike Matrigali <mikem_app@sbcglobal.net> wrote:
It is likely that they can be deleted, that they refer to stuff the
predates the derby codeline.  I can't think of any persistent datatype
that we got rid of since 10.0.  To be absolutely safe one should check
the 10.0 codeline as I can imagine horrible issues with reusing an
existing format id for some on existing on disk datatype (again I don't
remember us getting rid of anything but checking the code is always best
- and note that the class comment is just that - a comment.  It could me
that the class was moved without updating the comment.


Mamta Satoor wrote:
> Hello,
>
> I was going through iapi.services.io.StoredFormatIds to understand how
> SQLChar is generated by the compiler. I need to understand this in order
> to support generation of SQLChar with their own collator.
>
> In StoredFormatIds, I see several references to classes in the comments
> that don't really exist in Derby. For instance, there is following piece
> of code is StoredFormatIds
>
>         /**
>             class org.apache.derby.catalog.types.CharTypeIdImpl
>          */
>         static public final int CHAR_TYPE_ID_IMPL =
>             (MIN_ID_2 + 17);
>
> But there is no CharTypeIdImpl in the catalog.types package. Are these
> comments leftover from the past which should have been fixed?
>
> Thanks,
> Mamta


------=_Part_35388_14849484.1173819106648--