[jira] [Commented] (JENA-512) SSE Tags are used inconsistently
[ https://issues.apache.org/jira/browse/JENA-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13742523#comment-13742523 ] Hudson commented on JENA-512: - SUCCESS: Integrated in Jena_Development_Test #845 (See [https://builds.apache.org/job/Jena_Development_Test/845/]) JENA-512 Put algebra function names in Tags. Add equivalent builders for expessions by function name. Use constants in E_* classes. Rename printName as functionName. Some tests. (andy: rev 1514832) * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Add.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Conditional.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Divide.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Equals.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_GreaterThan.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_GreaterThanOrEqual.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_LessThan.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_LessThanOrEqual.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_LogicalAnd.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_LogicalNot.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_LogicalOr.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Multiply.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_NotEquals.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_NotOneOf.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_OneOf.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_SameTerm.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Subtract.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_UnaryMinus.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_UnaryPlus.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/ExprFunction.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/sse/Tags.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/sse/builders/BuilderExpr.java * /jena/trunk/jena-arq/src/test/java/com/hp/hpl/jena/sparql/syntax/TestSSE_Builder.java > SSE Tags are used inconsistently > > > Key: JENA-512 > URL: https://issues.apache.org/jira/browse/JENA-512 > Project: Apache Jena > Issue Type: Bug > Components: ARQ >Affects Versions: Jena 2.10.1 >Reporter: Rob Vesse >Assignee: Rob Vesse >Priority: Minor > Labels: algebra, sse > Fix For: Jena 2.10.2 > > > In some of our more recent code we are trying to map functions into a > messaging data structure by inspecting the function symbol. However we have > found that there are some inconsistencies in the symbols. > Namely that the capitalization and punctuation are not consistent, likely > this cannot change as it would mean breaking many existing algebra > examples/tests and systems like ours that use algebra strings internally. > The more concerning inconsistencies are that some functions report symbols > without using the tag constants and so some queries written report symbols > that don't match their tag constants. > BuilderExpr appears to get around this by doing case insensitive key lookup > which seems very hacky > There is also at least one function (isNumeric) which has no Tag constant and > no SSE builder defined for it so queries containing this cannot be decoded > from algebra. > I plan to do two things: > - Make expression classes return their Tags constant where they don't already > and particularly in the cases where the two values aren't exact matches > - Fix the isNumeric case (and any others I discover) where there is no > registered builder for the symbol -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-512) SSE Tags are used inconsistently
[ https://issues.apache.org/jira/browse/JENA-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13742493#comment-13742493 ] Andy Seaborne commented on JENA-512: ExprFunction has three operations: getFunctionPrintName -- Used by the SPARQL formatter getFunctionName -- Used by the algebra formatter getOpName -- return the symbol name like '+' I've removed in-class constants and put all printNames (renamed functionName) into Tags. Given names to symbol-only things like "=" as "eq". > SSE Tags are used inconsistently > > > Key: JENA-512 > URL: https://issues.apache.org/jira/browse/JENA-512 > Project: Apache Jena > Issue Type: Bug > Components: ARQ >Affects Versions: Jena 2.10.1 >Reporter: Rob Vesse >Assignee: Rob Vesse >Priority: Minor > Labels: algebra, sse > > In some of our more recent code we are trying to map functions into a > messaging data structure by inspecting the function symbol. However we have > found that there are some inconsistencies in the symbols. > Namely that the capitalization and punctuation are not consistent, likely > this cannot change as it would mean breaking many existing algebra > examples/tests and systems like ours that use algebra strings internally. > The more concerning inconsistencies are that some functions report symbols > without using the tag constants and so some queries written report symbols > that don't match their tag constants. > BuilderExpr appears to get around this by doing case insensitive key lookup > which seems very hacky > There is also at least one function (isNumeric) which has no Tag constant and > no SSE builder defined for it so queries containing this cannot be decoded > from algebra. > I plan to do two things: > - Make expression classes return their Tags constant where they don't already > and particularly in the cases where the two values aren't exact matches > - Fix the isNumeric case (and any others I discover) where there is no > registered builder for the symbol -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-512) SSE Tags are used inconsistently
[ https://issues.apache.org/jira/browse/JENA-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13742492#comment-13742492 ] ASF subversion and git services commented on JENA-512: -- Commit 1514832 from [~andy.seaborne] in branch 'jena/trunk' [ https://svn.apache.org/r1514832 ] JENA-512 Put algebra function names in Tags. Add equivalent builders for expessions by function name. Use constants in E_* classes. Rename printName as functionName. Some tests. > SSE Tags are used inconsistently > > > Key: JENA-512 > URL: https://issues.apache.org/jira/browse/JENA-512 > Project: Apache Jena > Issue Type: Bug > Components: ARQ >Affects Versions: Jena 2.10.1 >Reporter: Rob Vesse >Assignee: Rob Vesse >Priority: Minor > Labels: algebra, sse > > In some of our more recent code we are trying to map functions into a > messaging data structure by inspecting the function symbol. However we have > found that there are some inconsistencies in the symbols. > Namely that the capitalization and punctuation are not consistent, likely > this cannot change as it would mean breaking many existing algebra > examples/tests and systems like ours that use algebra strings internally. > The more concerning inconsistencies are that some functions report symbols > without using the tag constants and so some queries written report symbols > that don't match their tag constants. > BuilderExpr appears to get around this by doing case insensitive key lookup > which seems very hacky > There is also at least one function (isNumeric) which has no Tag constant and > no SSE builder defined for it so queries containing this cannot be decoded > from algebra. > I plan to do two things: > - Make expression classes return their Tags constant where they don't already > and particularly in the cases where the two values aren't exact matches > - Fix the isNumeric case (and any others I discover) where there is no > registered builder for the symbol -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-512) SSE Tags are used inconsistently
[ https://issues.apache.org/jira/browse/JENA-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741195#comment-13741195 ] Rob Vesse commented on JENA-512: Yes I think there may be such as langmatches The advantage of using the Tags constants is now we can tweak them as necessary and they should automatically be reflected everywhere. I have tweaked sameTerm and langMatches appropriately but there may be others we want to tweak. Since both SSE and SPARQL itself have case insensitive keywords the exact capitalization is a matter of taste. Please go ahead and tweak the constants in Tags as you feel appropriate > SSE Tags are used inconsistently > > > Key: JENA-512 > URL: https://issues.apache.org/jira/browse/JENA-512 > Project: Apache Jena > Issue Type: Bug > Components: ARQ >Affects Versions: Jena 2.10.1 >Reporter: Rob Vesse >Assignee: Rob Vesse >Priority: Minor > Labels: algebra, sse > > In some of our more recent code we are trying to map functions into a > messaging data structure by inspecting the function symbol. However we have > found that there are some inconsistencies in the symbols. > Namely that the capitalization and punctuation are not consistent, likely > this cannot change as it would mean breaking many existing algebra > examples/tests and systems like ours that use algebra strings internally. > The more concerning inconsistencies are that some functions report symbols > without using the tag constants and so some queries written report symbols > that don't match their tag constants. > BuilderExpr appears to get around this by doing case insensitive key lookup > which seems very hacky > There is also at least one function (isNumeric) which has no Tag constant and > no SSE builder defined for it so queries containing this cannot be decoded > from algebra. > I plan to do two things: > - Make expression classes return their Tags constant where they don't already > and particularly in the cases where the two values aren't exact matches > - Fix the isNumeric case (and any others I discover) where there is no > registered builder for the symbol -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-512) SSE Tags are used inconsistently
[ https://issues.apache.org/jira/browse/JENA-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741194#comment-13741194 ] Hudson commented on JENA-512: - SUCCESS: Integrated in Jena_Development_Test #843 (See [https://builds.apache.org/job/Jena_Development_Test/843/]) Change capitalization on a couple of Tags constants to produce more readable query serializations (JENA-512) (rvesse: rev 1514373) * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/sse/Tags.java > SSE Tags are used inconsistently > > > Key: JENA-512 > URL: https://issues.apache.org/jira/browse/JENA-512 > Project: Apache Jena > Issue Type: Bug > Components: ARQ >Affects Versions: Jena 2.10.1 >Reporter: Rob Vesse >Assignee: Rob Vesse >Priority: Minor > Labels: algebra, sse > > In some of our more recent code we are trying to map functions into a > messaging data structure by inspecting the function symbol. However we have > found that there are some inconsistencies in the symbols. > Namely that the capitalization and punctuation are not consistent, likely > this cannot change as it would mean breaking many existing algebra > examples/tests and systems like ours that use algebra strings internally. > The more concerning inconsistencies are that some functions report symbols > without using the tag constants and so some queries written report symbols > that don't match their tag constants. > BuilderExpr appears to get around this by doing case insensitive key lookup > which seems very hacky > There is also at least one function (isNumeric) which has no Tag constant and > no SSE builder defined for it so queries containing this cannot be decoded > from algebra. > I plan to do two things: > - Make expression classes return their Tags constant where they don't already > and particularly in the cases where the two values aren't exact matches > - Fix the isNumeric case (and any others I discover) where there is no > registered builder for the symbol -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-512) SSE Tags are used inconsistently
[ https://issues.apache.org/jira/browse/JENA-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741182#comment-13741182 ] ASF subversion and git services commented on JENA-512: -- Commit 1514373 from [~rvesse] in branch 'jena/trunk' [ https://svn.apache.org/r1514373 ] Change capitalization on a couple of Tags constants to produce more readable query serializations (JENA-512) > SSE Tags are used inconsistently > > > Key: JENA-512 > URL: https://issues.apache.org/jira/browse/JENA-512 > Project: Apache Jena > Issue Type: Bug > Components: ARQ >Affects Versions: Jena 2.10.1 >Reporter: Rob Vesse >Assignee: Rob Vesse >Priority: Minor > Labels: algebra, sse > > In some of our more recent code we are trying to map functions into a > messaging data structure by inspecting the function symbol. However we have > found that there are some inconsistencies in the symbols. > Namely that the capitalization and punctuation are not consistent, likely > this cannot change as it would mean breaking many existing algebra > examples/tests and systems like ours that use algebra strings internally. > The more concerning inconsistencies are that some functions report symbols > without using the tag constants and so some queries written report symbols > that don't match their tag constants. > BuilderExpr appears to get around this by doing case insensitive key lookup > which seems very hacky > There is also at least one function (isNumeric) which has no Tag constant and > no SSE builder defined for it so queries containing this cannot be decoded > from algebra. > I plan to do two things: > - Make expression classes return their Tags constant where they don't already > and particularly in the cases where the two values aren't exact matches > - Fix the isNumeric case (and any others I discover) where there is no > registered builder for the symbol -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-512) SSE Tags are used inconsistently
[ https://issues.apache.org/jira/browse/JENA-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13740861#comment-13740861 ] Andy Seaborne commented on JENA-512: Rob - some of this predates Tags.* so thanks for cleaning it up. Which ones are inconsistent? It may not matter if they are changed. The case insensitive lookup in BuilderExpr is because these expressions may be written by people. "isIri" vs "isiri" vs "isIRI" shouldn't matter. > SSE Tags are used inconsistently > > > Key: JENA-512 > URL: https://issues.apache.org/jira/browse/JENA-512 > Project: Apache Jena > Issue Type: Bug > Components: ARQ >Affects Versions: Jena 2.10.1 >Reporter: Rob Vesse >Assignee: Rob Vesse >Priority: Minor > Labels: algebra, sse > > In some of our more recent code we are trying to map functions into a > messaging data structure by inspecting the function symbol. However we have > found that there are some inconsistencies in the symbols. > Namely that the capitalization and punctuation are not consistent, likely > this cannot change as it would mean breaking many existing algebra > examples/tests and systems like ours that use algebra strings internally. > The more concerning inconsistencies are that some functions report symbols > without using the tag constants and so some queries written report symbols > that don't match their tag constants. > BuilderExpr appears to get around this by doing case insensitive key lookup > which seems very hacky > There is also at least one function (isNumeric) which has no Tag constant and > no SSE builder defined for it so queries containing this cannot be decoded > from algebra. > I plan to do two things: > - Make expression classes return their Tags constant where they don't already > and particularly in the cases where the two values aren't exact matches > - Fix the isNumeric case (and any others I discover) where there is no > registered builder for the symbol -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-512) SSE Tags are used inconsistently
[ https://issues.apache.org/jira/browse/JENA-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13740467#comment-13740467 ] Hudson commented on JENA-512: - FAILURE: Integrated in Jena_Development_Test #839 (See [https://builds.apache.org/job/Jena_Development_Test/839/]) Use correct Tags constant for E_UnaryMinus (JENA-512) (rvesse: rev 1514101) * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_UnaryMinus.java Ensure SPARQL built-in expressions use symbol constants from Tags wherever possible instead of hard coding values in each file (JENA-512) (rvesse: rev 1514099) * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Add.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_BNode.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Bound.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Call.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Coalesce.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Conditional.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Datatype.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Divide.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Equals.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Exists.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_GreaterThan.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_GreaterThanOrEqual.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_IRI.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_IsBlank.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_IsIRI.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_IsLiteral.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_IsNumeric.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_IsURI.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Lang.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_LangMatches.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_LessThan.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_LessThanOrEqual.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_LogicalAnd.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_LogicalNot.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_LogicalOr.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Multiply.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_NotEquals.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_NotExists.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_NotOneOf.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_OneOf.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Random.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Regex.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_SameTerm.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Str.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_StrConcat.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_StrDatatype.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_StrLang.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Subtract.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_URI.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_UnaryMinus.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_UnaryPlus.java > SSE Tags are used inconsistently > > > Key: JENA-512 > URL: https://issues.apache.org/jira/browse/JENA-512 > Project: Apache Jena > Issue Type: Bug > Components: ARQ >Affects Versions: Jena 2.10.1 >Reporter: Rob Vesse >Assignee: Rob Vesse >Priority: Minor > Labels: algebra, sse > > In some of our more recent code we are trying to map functions into a > messaging data structure by inspecting the function symbol. However we have > found that there are some inconsistencies in the symbols. > Namely that the capitalization and punctuation are not consistent, likely > this cannot change as it would mean breaking many existing algebra > examples/tests and systems like ours that use algebra strings internally. > The more concerning inconsistencies are that some functions report symbols > without using the tag constants and so
[jira] [Commented] (JENA-512) SSE Tags are used inconsistently
[ https://issues.apache.org/jira/browse/JENA-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13740433#comment-13740433 ] ASF subversion and git services commented on JENA-512: -- Commit 1514101 from [~rvesse] in branch 'jena/trunk' [ https://svn.apache.org/r1514101 ] Use correct Tags constant for E_UnaryMinus (JENA-512) > SSE Tags are used inconsistently > > > Key: JENA-512 > URL: https://issues.apache.org/jira/browse/JENA-512 > Project: Apache Jena > Issue Type: Bug > Components: ARQ >Affects Versions: Jena 2.10.1 >Reporter: Rob Vesse >Assignee: Rob Vesse >Priority: Minor > Labels: algebra, sse > > In some of our more recent code we are trying to map functions into a > messaging data structure by inspecting the function symbol. However we have > found that there are some inconsistencies in the symbols. > Namely that the capitalization and punctuation are not consistent, likely > this cannot change as it would mean breaking many existing algebra > examples/tests and systems like ours that use algebra strings internally. > The more concerning inconsistencies are that some functions report symbols > without using the tag constants and so some queries written report symbols > that don't match their tag constants. > BuilderExpr appears to get around this by doing case insensitive key lookup > which seems very hacky > There is also at least one function (isNumeric) which has no Tag constant and > no SSE builder defined for it so queries containing this cannot be decoded > from algebra. > I plan to do two things: > - Make expression classes return their Tags constant where they don't already > and particularly in the cases where the two values aren't exact matches > - Fix the isNumeric case (and any others I discover) where there is no > registered builder for the symbol -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-512) SSE Tags are used inconsistently
[ https://issues.apache.org/jira/browse/JENA-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13740429#comment-13740429 ] Hudson commented on JENA-512: - SUCCESS: Integrated in Jena_Development_Test #838 (See [https://builds.apache.org/job/Jena_Development_Test/838/]) Add unit tests for isNumeric case (JENA-512) (rvesse: rev 1514087) * /jena/trunk/jena-arq/src/test/java/com/hp/hpl/jena/sparql/syntax/TestSSE_Builder.java Add Tags.tagIsNumeric and associated SSE builder (JENA-512) (rvesse: rev 1514086) * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/sse/Tags.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/sse/builders/BuilderExpr.java > SSE Tags are used inconsistently > > > Key: JENA-512 > URL: https://issues.apache.org/jira/browse/JENA-512 > Project: Apache Jena > Issue Type: Bug > Components: ARQ >Affects Versions: Jena 2.10.1 >Reporter: Rob Vesse >Assignee: Rob Vesse >Priority: Minor > Labels: algebra, sse > > In some of our more recent code we are trying to map functions into a > messaging data structure by inspecting the function symbol. However we have > found that there are some inconsistencies in the symbols. > Namely that the capitalization and punctuation are not consistent, likely > this cannot change as it would mean breaking many existing algebra > examples/tests and systems like ours that use algebra strings internally. > The more concerning inconsistencies are that some functions report symbols > without using the tag constants and so some queries written report symbols > that don't match their tag constants. > BuilderExpr appears to get around this by doing case insensitive key lookup > which seems very hacky > There is also at least one function (isNumeric) which has no Tag constant and > no SSE builder defined for it so queries containing this cannot be decoded > from algebra. > I plan to do two things: > - Make expression classes return their Tags constant where they don't already > and particularly in the cases where the two values aren't exact matches > - Fix the isNumeric case (and any others I discover) where there is no > registered builder for the symbol -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-512) SSE Tags are used inconsistently
[ https://issues.apache.org/jira/browse/JENA-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13740425#comment-13740425 ] ASF subversion and git services commented on JENA-512: -- Commit 1514099 from [~rvesse] in branch 'jena/trunk' [ https://svn.apache.org/r1514099 ] Ensure SPARQL built-in expressions use symbol constants from Tags wherever possible instead of hard coding values in each file (JENA-512) > SSE Tags are used inconsistently > > > Key: JENA-512 > URL: https://issues.apache.org/jira/browse/JENA-512 > Project: Apache Jena > Issue Type: Bug > Components: ARQ >Affects Versions: Jena 2.10.1 >Reporter: Rob Vesse >Assignee: Rob Vesse >Priority: Minor > Labels: algebra, sse > > In some of our more recent code we are trying to map functions into a > messaging data structure by inspecting the function symbol. However we have > found that there are some inconsistencies in the symbols. > Namely that the capitalization and punctuation are not consistent, likely > this cannot change as it would mean breaking many existing algebra > examples/tests and systems like ours that use algebra strings internally. > The more concerning inconsistencies are that some functions report symbols > without using the tag constants and so some queries written report symbols > that don't match their tag constants. > BuilderExpr appears to get around this by doing case insensitive key lookup > which seems very hacky > There is also at least one function (isNumeric) which has no Tag constant and > no SSE builder defined for it so queries containing this cannot be decoded > from algebra. > I plan to do two things: > - Make expression classes return their Tags constant where they don't already > and particularly in the cases where the two values aren't exact matches > - Fix the isNumeric case (and any others I discover) where there is no > registered builder for the symbol -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-512) SSE Tags are used inconsistently
[ https://issues.apache.org/jira/browse/JENA-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13740382#comment-13740382 ] ASF subversion and git services commented on JENA-512: -- Commit 1514087 from [~rvesse] in branch 'jena/trunk' [ https://svn.apache.org/r1514087 ] Add unit tests for isNumeric case (JENA-512) > SSE Tags are used inconsistently > > > Key: JENA-512 > URL: https://issues.apache.org/jira/browse/JENA-512 > Project: Apache Jena > Issue Type: Bug > Components: ARQ >Affects Versions: Jena 2.10.1 >Reporter: Rob Vesse >Assignee: Rob Vesse >Priority: Minor > Labels: algebra, sse > > In some of our more recent code we are trying to map functions into a > messaging data structure by inspecting the function symbol. However we have > found that there are some inconsistencies in the symbols. > Namely that the capitalization and punctuation are not consistent, likely > this cannot change as it would mean breaking many existing algebra > examples/tests and systems like ours that use algebra strings internally. > The more concerning inconsistencies are that some functions report symbols > without using the tag constants and so some queries written report symbols > that don't match their tag constants. > BuilderExpr appears to get around this by doing case insensitive key lookup > which seems very hacky > There is also at least one function (isNumeric) which has no Tag constant and > no SSE builder defined for it so queries containing this cannot be decoded > from algebra. > I plan to do two things: > - Make expression classes return their Tags constant where they don't already > and particularly in the cases where the two values aren't exact matches > - Fix the isNumeric case (and any others I discover) where there is no > registered builder for the symbol -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-512) SSE Tags are used inconsistently
[ https://issues.apache.org/jira/browse/JENA-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13740381#comment-13740381 ] ASF subversion and git services commented on JENA-512: -- Commit 1514086 from [~rvesse] in branch 'jena/trunk' [ https://svn.apache.org/r1514086 ] Add Tags.tagIsNumeric and associated SSE builder (JENA-512) > SSE Tags are used inconsistently > > > Key: JENA-512 > URL: https://issues.apache.org/jira/browse/JENA-512 > Project: Apache Jena > Issue Type: Bug > Components: ARQ >Affects Versions: Jena 2.10.1 >Reporter: Rob Vesse >Assignee: Rob Vesse >Priority: Minor > Labels: algebra, sse > > In some of our more recent code we are trying to map functions into a > messaging data structure by inspecting the function symbol. However we have > found that there are some inconsistencies in the symbols. > Namely that the capitalization and punctuation are not consistent, likely > this cannot change as it would mean breaking many existing algebra > examples/tests and systems like ours that use algebra strings internally. > The more concerning inconsistencies are that some functions report symbols > without using the tag constants and so some queries written report symbols > that don't match their tag constants. > BuilderExpr appears to get around this by doing case insensitive key lookup > which seems very hacky > There is also at least one function (isNumeric) which has no Tag constant and > no SSE builder defined for it so queries containing this cannot be decoded > from algebra. > I plan to do two things: > - Make expression classes return their Tags constant where they don't already > and particularly in the cases where the two values aren't exact matches > - Fix the isNumeric case (and any others I discover) where there is no > registered builder for the symbol -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
