2 Replies Latest reply on Dec 4, 2012 6:28 PM by Brian Wallis

    Queries, Sorting and Internationalisation

    Brian Wallis Master

      I've just read the post at https://community.jboss.org/message/649293#649293 and am wondering what support there is for localisation of the comparison functions in a query.


      • can ORDER BY be influenced by a locale setting?
      • Can a string comparison be influenced by a local setting


      where I mean "influenced by" as in behaviour similar to that of the java.lang.Comparator class.


      What I would expect is that my thread's current locale is used to determine how comparisons are performed in the execution of the JCR-SQL2 expression. Of course there is no (to my knowledge) standard way to store/retrieve the current thread's prefered locale. There are the getLocales() and getLocale() methods on the ServletRequest for web apps but nothing for stuff lower in the stack so this is something I would need to supply to the JCR when I execute the query. I'm probably going to have a locale value available in my user session object.


      So... What locale *does* the JCR-SQL2 executor use? The JVM wide locale setting? Hibernate has a setLocale() method on the Query interface and I'd guess it sets the locale used in the query but the wealth of documentation on this leaves one guessing :-( Is there something similar for ModeShape (3)?



        • 1. Re: Queries, Sorting and Internationalisation
          Randall Hauch Master

          How text is stored in the indexes and queried is determined by a Lucene Analyzer (see this good summary article), and by default ModeShape uses a StandardAnalyzer. So you could choose a different analyzer if one better suits your need, but doing so affects the whole repository.


          JCR has very limited support for localized properties: there are some built-in mixins and property definitions for storing locales. But that's about it. There is currently no way to specify locale-specific ordering or comparison. However, we are using Comparator implementations (which just use String equals and compareTo methods, and thus completely unaware of locales) within our sorting and comparison operations. This can be corrected: it's really just a matter of figuring out a way to client to supply the desired locale (e.g., via something like what you mentioned above), and then adjusting the engine to use a Collator for that locale. It seems deceptively simple, because we'd have to change lots of signatures (to pass the desired locale) of lots of methods used in the preparation of the queries. But it's probably worth doing.


          Feel free to log an enhancment.

          • 2. Re: Queries, Sorting and Internationalisation
            Brian Wallis Master

            Thanks, I've created MODE-1727 to cover this.


            A way that affect the whole repository doesn't really work for my usecase as the locale used should be that specified by a particular user in a particular session and may even be changed during the session if the user wants to (unlikely but possible). That said, I will look at that as a possible short term solution in our first release where a server installation probably only uses a single locale setting, not user selectable.


            This is not a show stopper and for us is probably not first release functionality, I'm just covering the bases to make sure we can do this in later releases without too much rework. Internationalisation can be a trap if not considered early on, it gets harder to retrofit the larger your code base grows.