[
https://issues.apache.org/jira/browse/DERBY-3975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654810#action_12654810
]
Knut Anders Hatlen commented on DERBY-3975:
-------------------------------------------
I don't think we store the hash values anywhere, so to my knowledge they just
have to be consistent within the lifetime of the JVM. The only place I know
that the hash values will go to disk, is when a BackingStoreHashtable spills to
disk, but that's just in a temporary file that will be deleted on the next
boot, as far as I know.
> SELECT DISTINCT may return duplicates with territory-based collation
> --------------------------------------------------------------------
>
> Key: DERBY-3975
> URL: https://issues.apache.org/jira/browse/DERBY-3975
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.4.2.0
> Reporter: Knut Anders Hatlen
> Assignee: Knut Anders Hatlen
> Attachments: AisBCollatorProvider.java
>
>
> I defined my own locale (en_US_aisb) where the collation rules said that a=b.
> When I tried queries with SELECT DISTINCT, they didn't always eliminate all
> duplicates. Here's an example:
> ij> connect
> 'jdbc:derby:db;create=true;territory=en_US_aisb;collation=TERRITORY_BASED';
> ij> create table t (x varchar(10));
> 0 rows inserted/updated/deleted
> ij> insert into t values 'a','b','abba','baab','ABBA';
> 5 rows inserted/updated/deleted
> ij> select distinct * from t;
> X
> ----------
> ABBA
> b
> a
> abba
> 4 rows selected
> ij> select distinct * from t order by x;
> X
> ----------
> a
> abba
> ABBA
> 3 rows selected
> The first query did eliminate the duplicate "abba"/"baab", but it did not
> eliminate the duplicate "a"/"b". When an ORDER BY clause was added (the
> second query), all the duplicates were eliminated.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
