You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by "Andy Seaborne (JIRA)" <ji...@apache.org> on 2014/06/20 11:37:24 UTC
[jira] [Commented] (JENA-721) Inline literals, source types are
discarded
[ https://issues.apache.org/jira/browse/JENA-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14038618#comment-14038618 ]
Andy Seaborne commented on JENA-721:
------------------------------------
[~mortern] -- what problem is it causing you?
There are two effects - canonicalization (001 is the same as +1) and derived type promotion (xsd:byte goes to xsd:integer).
It makes comparisons "by value" within the derived type hierarchy for xsd;integer so SPARQL {{?s :property +1}} match data {{:subject :property "01"^^xsd:positiveInteger}}.
> Inline literals, source types are discarded
> -------------------------------------------
>
> Key: JENA-721
> URL: https://issues.apache.org/jira/browse/JENA-721
> Project: Apache Jena
> Issue Type: Improvement
> Components: TDB
> Affects Versions: TDB 1.0.1
> Reporter: Marek Kowalczyk
>
> NodeId.inline$ changes the actual type of literals from subtypes of xsd:integer to xsd:integer, for instance: literals of type xsd:positiveInteger are stored ad inline type INTEGER and during read decoded as xsd:integer in NodeId.extract(NodeId)
> {code}
> case INTEGER:
> {
> long val = IntegerNode.unpack(v) ;
> Node n = NodeFactory.createLiteral(Long.toString(val), null, XSDDatatype.XSDinteger) ;
> return n ;
> }
> {code}
> It would be nice to add support for various xsd:types and use the 7 bits reserved for inline type to represent more than 7 types.
> As a fastest workaround I've disabled the inline literals in NodeId( using reflection) , but it would be great If it would be configurable via context or parameter in StoreConnection.make(); or via SystemParams
--
This message was sent by Atlassian JIRA
(v6.2#6252)