[
https://issues.apache.org/jira/browse/JENA-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15056431#comment-15056431
]
ASF GitHub Bot commented on JENA-1083:
--------------------------------------
GitHub user ajs6f opened a pull request:
https://github.com/apache/jena/pull/110
JENA-1083: Using ColumnMap in transaction in-memory dataset implementation
Okay, @afs : Second try. This time I avoid unneeded object creation or
packing and unpacking, and I don't do weird things to the semantics of `Quad`
and `Triple` (I hope!).
I did add some convenience methods to `ColumnMap` and also let the two
tuple types subtype `Tuple<Node>` in order to work more closely with
`ColumnMap`. I don't think this should be any problem, since they truly are
tuples, but I'm sure you will let me know if that is not the case :).
The gains here are much more clarity for the forms of
`PMapTupleTable`-based in-memory indexes and it should also be possible much
more easily to create other index orderings, if users find that useful for
special purposes. (I.e. saving space under conditions where the possible
queries are known and very restricted.)
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ajs6f/jena TuplesAreTuples
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/jena/pull/110.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #110
----
commit 64224ca320fd2989502e7699ec33283dc0fe6ff7
Author: ajs6f <[email protected]>
Date: 2015-12-14T18:13:15Z
Using ColumnMap in transaction in-memory dataset implementation
----
> MInor refactoring in TupleTables
> --------------------------------
>
> Key: JENA-1083
> URL: https://issues.apache.org/jira/browse/JENA-1083
> Project: Apache Jena
> Issue Type: Improvement
> Components: ARQ
> Reporter: A. Soroka
> Priority: Minor
>
> There are some minor refactorings available for TupleTable and its subtypes,
> particularly PMapTripleTable and PMapQuadTable that will clarify their use.
> Specifically, current impls of those abstract types have to override several
> methods for adding, removing, and finding tuples. In fact, the only
> information being added when those methods are overridden is conversion
> between canonical and internal tuple ordering. This refactoring is to provide
> methods that do that conversion and nothing else, which will make two methods
> the most that any implementation of those abstract classes will have to
> provide.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
