[
https://issues.apache.org/jira/browse/JENA-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14039225#comment-14039225
]
Andy Seaborne commented on JENA-721:
------------------------------------
While the code is structured as a stack of facilties, the encoding of values
into NodeIds goes all the way to the disk. It isn't a feature of some reasoner.
If a database is created with no NodeId layer in the NodeTable stack, it is
incompatible with running later with the NodeTable layer, and vice versa.
A validation as you describe can be done (more efficiently) as data is parsed
either immediately prior to loading or a separate validation step. I think the
latter is better - validate all data before attempting to load fixing in the
database can be messy (e.g. blank nodes) and othervalidation failures may even
break the loading step.
{{riot.infer}} is an example of a process that reads the schema then processes
the data in a streaming fashion.
Would that approach to validating datatypes, beforeTDB processes them as
values, work for you?
> 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)
