[
https://issues.apache.org/jira/browse/JENA-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16995491#comment-16995491
]
Andy Seaborne commented on JENA-1798:
-------------------------------------
Yes, this happens. TDB1 stores values, not the datatype. TDB2 stores RDF terms
with their datatype.
Changing this in TDB1 would be a change of disk format and so is not to be
undertaken lightly. If the majority of users want this, then it can be done by
taking the "inline" code from TDB2. I think it is backward compatible
Is it only the datatype constraint?
It is possible to detect when it's TDB1 and make the test "datatype is
compatible with"; at the moment it is "exactly the same".
> TDB1 converts small xsd:long literals into xsd:integer
> ------------------------------------------------------
>
> Key: JENA-1798
> URL: https://issues.apache.org/jira/browse/JENA-1798
> Project: Apache Jena
> Issue Type: Bug
> Components: TDB
> Reporter: Pavel Mikhailovskii
> Priority: Minor
>
> TDB1 converts small xsd:long literals, e.g. "1"^<xsd:long> to xsd:integer.
> This behavior is specific to TDB1. Even though that might be acceptable in
> most cases, it breaks validation of SHACL \{{ sh:dataType xsd:long ;}}
> constraints. The following test demonstrates the issue:
> {code:java}
> @Test public void longLiterals() {
> DatasetGraph dsg = TDBFactory.createDatasetGraph();
> Quad quad1 = SSE.parseQuad("(quad <g> <s> <p>
> \"1\"^^<http://www.w3.org/2001/XMLSchema#long>)");
> assertEquals(XSDDatatype.XSDlong,
> quad1.getObject().getLiteralDatatype());
> dsg.add(quad1);
> Quad quad2 = dsg.find().next();
> assertEquals(XSDDatatype.XSDlong,
> quad2.getObject().getLiteralDatatype());
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
