Github user kinow commented on a diff in the pull request:
https://github.com/apache/jena/pull/237#discussion_r116342551
--- Diff: jena-arq/src/main/java/org/apache/jena/sparql/expr/NodeValue.java
---
@@ -783,6 +772,22 @@ private static int compare(NodeValue nv1, NodeValue
nv2, boolean sortOrderingCom
return Expr.CMP_GREATER ;
return Expr.CMP_EQUAL; // Both plain or both xsd:string.
}
+ case VSPACE_SORTKEY :
+ {
+ int cmp = 0;
+ String c1 = nv1.getCollation();
+ String c2 = nv2.getCollation();
+ if (c1 != null && c2 != null && c1.equals(c2)) {
+ // locales are parsed. Here we could think about
caching if necessary
+ Locale desiredLocale = Locale.forLanguageTag(c1);
+ // collators are already stored in a concurrent map by
the JVM, with <locale, softref<collator>>
+ Collator collator =
Collator.getInstance(desiredLocale);
+ cmp = collator.compare(nv1.getString(),
nv2.getString());
+ } else {
--- End diff --
What a great idea being comparable! Done, it reduced changes in NodeValue,
and made writing tests for the comparison (core part of this change) easier.
Thanks Andy!
As for the general mechanism, I'd be +1, but maybe later I think. The class
is final for now and has a few comments. If I understand it correctly, someone
in the future may remove the final mark, remove the collation and move it to
subtype/enums. This way we could re-use `NodeSortKey` later for comparing other
things. One could even write a simple function that would compare values by
some string edit distance.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
