Re: Language based matching

2006-07-13 Thread Bryan Pendleton
Is there some easy Java regular expression matching function like String.matches(Collator collator, String pattern, String value)? Here's an article from 1999 in which some person apparently decided that they needed to write such a thing themselves. Warning: the code described in this

Re: Language based matching

2006-07-12 Thread Kathey Marsden
Rick Hillegas wrote: 3) The locale-sensitive meaning of , =, and affected the operation of all orderings of national strings, including sorts, indexes, unions, group-by's, like's, between's, and in's. At one point I was keen on re-enabling the national string types. Now I am leaning

Re: Language based matching

2006-07-12 Thread Rick Hillegas
Hi Kathey, My gut feeling is that you are headed off into the tall weeds here. That said, let me walk with you part way into the swamp. Another feature you might want would be DERBY-481, computed columns. This would help you get better performance. So, for instance, you could declare your

Re: Language based matching

2006-07-12 Thread Kathey Marsden
Rick Hillegas wrote: [ some interesting stuff about performance] LIKE is going to be a pile of work. I think your LOCALE_MATCHES function will have to duplicate a lot of the code in Derby. At the end of the day, you will replace LIKE with LOCALE_MATCHES and so lose the performance-enhancing

Re: Language based matching

2006-07-12 Thread Rick Hillegas
Kathey Marsden wrote: Rick Hillegas wrote: [ some interesting stuff about performance] LIKE is going to be a pile of work. I think your LOCALE_MATCHES function will have to duplicate a lot of the code in Derby. At the end of the day, you will replace LIKE with LOCALE_MATCHES and so lose

Re: Language based matching

2006-07-12 Thread Satheesh Bandaram
Rick Hillegas wrote: At one point I was keen on re-enabling the national string types. Now I am leaning toward implementing the ANSI collation language. I think this is more powerful. In particular, it lets you support more than one language-sensitive ordering in the same database. I also

Re: Language based matching

2006-07-11 Thread Bernt M. Johnsen
aa as one letter was removed from the Norwegian language in 1938 (å had been optional since 1917). It is only used in names today and it is true what Anders says about the phonebook (also about the foreign names where aa is treated like two letters). I don't think it would be wise to not let a.*

Re: Language based matching

2006-07-11 Thread Kathey Marsden
Bernt M. Johnsen wrote: aa as one letter was removed from the Norwegian language in 1938 (å had been optional since 1917). It is only used in names today and it is true what Anders says about the phonebook (also about the foreign names where aa is treated like two letters). I don't think it

Re: Language based matching

2006-07-11 Thread Daniel John Debrunner
Bernt M. Johnsen wrote: aa as one letter was removed from the Norwegian language in 1938 (å had been optional since 1917). It is only used in names today and it is true what Anders says about the phonebook (also about the foreign names where aa is treated like two letters). I don't think it

Re: Language based matching

2006-07-11 Thread Rick Hillegas
Hi Kathey, Here is my understanding of how the disabled national string types worked: 1) A national string type used the collation ordering appropriate to the locale of the database. That collation ordering, in turn, was specified by the jdk and could not be overriden. 2) The collation

Re: Language based matching

2006-07-10 Thread Knut Anders Hatlen
Kathey Marsden [EMAIL PROTECTED] writes: Does anyone know of an easy built in Java mechanism for Locale sensitive matching? I continue to work with a user trying to develop a strategy for language based string type handling in Derby 10.1. The ordering seems doable with the approach in

Language based matching

2006-07-07 Thread Kathey Marsden
Does anyone know of an easy built in Java mechanism for Locale sensitive matching? I continue to work with a user trying to develop a strategy for language based string type handling in Derby 10.1. The ordering seems doable with the approach in