On Mon, Nov 10, 2014 at 12:12 PM, Thomas Mortagne <[email protected]> wrote: > On Mon, Nov 10, 2014 at 12:03 PM, Eduard Moraru <[email protected]> wrote: >> Hi Marius, >> >> On Mon, Nov 10, 2014 at 12:24 PM, Marius Dumitru Florea < >> [email protected]> wrote: >> >>> I'm undecided. As a technical Linux user I prefer case sensitivity, but I >>> can see why this is sometimes unexpected for non-technical users. I'm not >>> sure how you plan to implement this. I know this thread is not about the >>> technical aspects but still I think it's important to consider the cost >>> that this change will imply. >>> >>> First, even for a case insensitive system, I think it's very important to >>> preserve the case entered by the user. For instance, If I create a user >>> with the alias 'myCoolAlias' then I wouldn't like to see 'mycoolalias' >>> displayed in the UI. Same, if I attach a file named >>> 'myCoolPresentation.odp' then I want to see precisely that name on the list >>> of attachments. So we need to store case sensitive values in the database. >>> >> The difference from now will be: >>> >>> * when creating an entity: check that there's no other entity that has the >>> same normalized reference (toLowerCase/toUpperCase) >>> >>> * when retrieving an entity: look for normalized references >>> >>> This means we'll have to call toLowerCase/toUpperCase very often so we need >>> proper database indexes. Otherwise we'll have a performance impact. >>> >> >> Right. I posted a similar comment on the Jira issue. >> >> Another interesting idea I was just thinking about would be to add >> uniqueness constraints in the database on lower(doc.fullName) for instance. >> That would cover the creation step. >> >> Regarding performance, I have found in some quick searches that uniqueness >> constraints are also achievable through unique function-based indexes [1]. >> >> On both cases, we would have to investigate on the database support or >> solutions for using a function like lower() for the database unique >> constraint or the unique index. >> >> ---------- >> [1] >> http://stackoverflow.com/questions/3944840/create-unqiue-case-insensitive-constraint-on-two-varchar-fields >> >> >>> Second, we have lots of places that query the database and since we have to >>> store the raw case-sensitive values then we need to update all this places. >>> Moreover, since it's not about a single field/column I'm not sure we can >>> write a query filter to lower the case automatically. Then we also have a >>> lot of extensions that query the database and that create entities. Those >>> will have to be updated too. >>> >> >> Not sure a filter would be the solution, since queries should be >> application-specific. >> >> >>> >>> Lastly, AFAIK lower case and upper case are locale dependent. The 'lower' >>> query function doesn't have a locale parameter so it depends on the locale >>> the database has been configured with. So there can be cases when a user >>> won't be able to retrieve an entity using some locale dependent lowercase >>> version of the reference because the database computes the lower case >>> differently than what the user expects (because it uses a different >>> locale). >>> >> >> Well, as long as we do something like lower(myValue) = lower(dbValue) >> instead of myValue = lower(dbValue), we should be good, right? (i. e. apply >> the same databse collation/logic on both the searched value and the db >> value so that we never get a missmatch). > > Not really, the problem you will have is that lower is not going to do > it's job because you are not in the right locale. That means that you > might end up with the request thinking that two values are not equals > while if lower did its job properly it would have been. In XWiki side > we will apply the locale to String.toLower and we will get a different > result which means that you have cases where in the require two > document name are not equals but they are when you compare two > DocumentReference which might create many issues.
s/require/request/ > >> >> Thanks, >> Eduard >> >> >>> >>> Thanks, >>> >>> Marius >>> >>> >>> On Nov 7, 2014 12:34 PM, "Eduard Moraru" <[email protected]> wrote: >>> > >>> > Hi users and devs, >>> > >>> > I would like to have your opinion on the topic of case sensitive vs case >>> > insensitive and which one you prefer in XWiki. >>> > >>> > Currently, XWiki is case sensitive. This means the same resource name >>> > (document name, space name, etc) can be written with either small letters >>> > or big letters or a mix. >>> > >>> > Examples: You can have both "Main.Test" and "Main.test" as 2 different >>> > documents. Also, you can have "XWiki.Admin" and "XWiki.admin" as 2 >>> > different users. This also applies to URLs, as "/Main/Test" is different >>> > from "/Main/test" or "/main/test", so all these 3 are different >>> resources. >>> > >>> > Even from this short description, one can already identify possible >>> > problems of this approach. >>> > >>> > From the top 3 operating systems (Linux, Mac an Windows), only Linux is >>> > case sensitive, the other two (more user-focused Operating Systems) are >>> > both case insensitive. >>> > >>> > Since XWiki has one of its main targets the Enterprise users, it is safe >>> to >>> > assume that the correct approach would be to also be more user-focused >>> and >>> > simplify things and avoid confusions by being case insensitive as well. >>> > >>> > Also, a quick search on existing issues validates the need for this >>> > improvement: >>> > http://jira.xwiki.org/issues/?jql=text%20~%20%22case%20insensitive%22 >>> > >>> > What do you think? Is it OK to keep XWiki case sensitive, or would you >>> > prefer it case insensitive? Bring arguments. >>> > >>> > I have also created a jira issue for this idea: >>> > http://jira.xwiki.org/browse/XWIKI-11412 to track it in the future. >>> > >>> > Thanks, >>> > Eduard >>> > _______________________________________________ >>> > devs mailing list >>> > [email protected] >>> > http://lists.xwiki.org/mailman/listinfo/devs >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >>> >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs > > > > -- > Thomas Mortagne -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
