db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta Satoor" <msat...@gmail.com>
Subject Re: comparisons between system and user table columns with TERRITORY_BASED collation
Date Tue, 26 Jun 2007 17:23:21 GMT
My earlier message was little vague. In the second paragraph, I am talking
about Jira entry DERBY-2668.

As for DERBY-2866, Kathey can I close it as a duplicate of DERBY-2668? I
think they are both talking about the same problem.

Mamta


On 6/26/07, Mamta Satoor <msatoor@gmail.com> wrote:
>
> Dan, I will go ahead and enter a Jira entry which will handle the task of
> checking how all the collation determination logic can be put in one central
> place.
>
> As for the error message, I agree that it is confusing. I will go ahead
> and put the comments from this thread about possibly using the actual
> collation type in the error message. I hope to work on this Jira entry after
> finishing couple other todos on collation.
>
> Mamta
>
>
> On 6/26/07, Daniel John Debrunner <djd@apache.org > wrote:
> >
> >
> > > Mike Matrigali < mikem_app@sbcglobal.net> writes:
> > >
> > >> This sounds like an easy solution to this issue, but will change the
> > >> error message for all comparison mismatches that are not territory
> > >> related.  Does that sound ok?
> >
> > I would have thought that there would be a different error message.
> > Looking at the comments in DERBY-2668 it seems to says a single message
> > is used because DataTypeDescriptor.comparable() is used to determine if
> > the collations are compatible for comparision. However, I'm not sure how
> >
> > this can be implementing the required logic behind collation
> > determination, which requires inspection of all the types involved, not
> > just two. I think this goes back to my concern that the required complex
> > logic for determining collation is not in a single method, rather spread
> >
> > out across several locations, each with different logic. Even the logic
> > in DTD.comparable does not match what is required by the SQL spec
> > (section 9.13 I think).
> >
> > Dan.
> >
> >
> >
>

Mime
View raw message