Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (herse.apache.org: domain of msatoor@gmail.com designates
 209.85.132.243 as permitted sender)
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=GDB2nOeHGRU/OIn3XL91I3SvjONOtxKx5/FEkIS7IWG9y0ZEh83N9qNGlf6RuESRDk3T2w4U+ih3Id3sngBTM4o9HzV7HuWSEEm77esnd81n+Xeczf+Jh0Z777xBC/4EPAiILGqaPWiYODZxkq90fCQPLRwV6XzmFGmMJ70sI2k=
Message-ID: <d9619e4a0704041341s3c81488ar5d4d0533796401f4@mail.gmail.com>
Date: Wed, 4 Apr 2007 13:41:07 -0700
From: "Mamta Satoor" <msatoor@gmail.com>
To: derby-dev@db.apache.org
Subject: Re: [jira] Updated: (DERBY-2524) DataTypeDescriptor(DTD) needs to
 have collation type and collation derivation. These new fields will apply
 only for character string types. Other types should ignore them.
In-Reply-To: <4613F3FE.8030704@apache.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_38408_8527420.1175719267544"
References: <6764026.1175710952245.JavaMail.jira@brutus>
	 <4613F3FE.8030704@apache.org>

------=_Part_38408_8527420.1175719267544
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Copied from Dan's mail
*************************************************************
> 2)Is it right to assume that readExternal and writeExternal methods in
> TypeDescriptorImpl will get called only for persistent columns?


Probably, though looking forward at some point the derivation will need
to be stored, might be worth thinking about this now to avoid future
upgrades.

*************************************************************
I wonder if precision field is available for character string types. If it
is available, then we can possibly use it to store collation derivation (I
will convert collation derivation to int in my followup patch) for character
string types.

Mamta


On 4/4/07, Daniel John Debrunner <djd@apache.org> wrote:
>
> Mamta A. Satoor (JIRA) wrote:
>
>
> > Questions
> > 1)I have included all the constant definitions related to collation in
> TypeDescriptor.
> > If anyone has suggestion on a better place to define them, let me know.
>
> I'd thought about defining such constants on StringDataValue since they
> only apply to character types.
>
> Why string constants for derivation though, why not integer values?
> Also there's no constant for error, though I would not recommend having
> an error value. Why not just use none as the default value? That will
> lead to the same behaviour, no collation suppported. Adding an error
> state is something that is not in the SQL standard.
>
> Note that the javadoc comments you added for these constants are only
> for the first constant, the others will have no javadoc.
>
> > 2)Is it right to assume that readExternal and writeExternal methods in
> > TypeDescriptorImpl will get called only for persistent columns?
>
> Probably, though looking forward at some point the derivation will need
> to be stored, might be worth thinking about this now to avoid future
> upgrades.
>
> Dan.
>
>
>
>

------=_Part_38408_8527420.1175719267544
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div>Copied from Dan&#39;s mail</div>
<div>*************************************************************</div>
<div><font color="#550055">&gt; 2)Is it right to assume that readExternal and writeExternal methods in<br>&gt; TypeDescriptorImpl will get called only for persistent columns?<br><br>&nbsp;</font></div>
<div style="DIRECTION: ltr">Probably, though looking forward at some point the derivation will need<br>to be stored, might be worth thinking about this now to avoid future<br>upgrades.<br>&nbsp;</div>
<div>*************************************************************</div>
<div>I wonder if precision field is available for character string types. If it is available, then we can possibly use it to store collation derivation (I will convert collation derivation to int in my followup patch)&nbsp;for character string types.
</div>
<div>&nbsp;</div>
<div>Mamta</div>
<div><br><br>&nbsp;</div>
<div><span class="gmail_quote">On 4/4/07, <b class="gmail_sendername">Daniel John Debrunner</b> &lt;<a href="mailto:djd@apache.org">djd@apache.org</a>&gt; wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Mamta A. Satoor (JIRA) wrote:<br><br><br>&gt; Questions<br>&gt; 1)I have included all the constant definitions related to collation in TypeDescriptor.
<br>&gt; If anyone has suggestion on a better place to define them, let me know.<br><br>I&#39;d thought about defining such constants on StringDataValue since they<br>only apply to character types.<br><br>Why string constants for derivation though, why not integer values?
<br>Also there&#39;s no constant for error, though I would not recommend having<br>an error value. Why not just use none as the default value? That will<br>lead to the same behaviour, no collation suppported. Adding an error
<br>state is something that is not in the SQL standard.<br><br>Note that the javadoc comments you added for these constants are only<br>for the first constant, the others will have no javadoc.<br><br>&gt; 2)Is it right to assume that readExternal and writeExternal methods in
<br>&gt; TypeDescriptorImpl will get called only for persistent columns?<br><br>Probably, though looking forward at some point the derivation will need<br>to be stored, might be worth thinking about this now to avoid future
<br>upgrades.<br><br>Dan.<br><br><br><br></blockquote></div><br>

------=_Part_38408_8527420.1175719267544--