[
https://issues.apache.org/jira/browse/JENA-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17237642#comment-17237642
]
Martin Pekár commented on JENA-1988:
------------------------------------
Right, I understand. But wouldn't it be possible to have an instance of
_baseTable_ for each node type? Then, whenever
__idForNode_ is called, I use the appropriate instance base on the type of node
passed to the method. When I call
__retrieveNodeByNodeId_, can't I search all instances of _baseTable_, even
though this wouldn't improve computation time?
> Separating B+ tree into different Node representations.
> -------------------------------------------------------
>
> Key: JENA-1988
> URL: https://issues.apache.org/jira/browse/JENA-1988
> Project: Apache Jena
> Issue Type: Question
> Components: TDB
> Affects Versions: Jena 3.16.0
> Reporter: Martin Pekár
> Priority: Major
> Labels: features, newbie, performance, test
> Fix For: Jena 3.16.0
>
> Attachments: NodeTableNative.java
>
>
> In a project to optimize the indexing, I am trying to have 4 indexes, one for
> each Node type (variable, literal, URI and blank). To implement this, I added
> 4 copies of the _nodeHashToId_ Index instance in the _NodeTableNative_ class.
> Then, for every operation on the _nodeHashToId_, for example using
> _containsNode()_ in the NodeTableNative class, I first check the type of Node
> given as parameter and then check for existence in the appropriate
> _nodeHashToId_ copy.
> Now, for some reason I get a NullPointerException when running the tests.
> Many of these exceptions appear in the _BufferChannelFile_ class in the
> _size()_ method because the call to _file.channel()_ return null.
> My question is then, is _NodeTableNative___ even the right place to implement
> this optimization, and second, if it is the right place to implement, can you
> help me understand why this exception is thrown?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
