[
https://issues.apache.org/jira/browse/JENA-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15089000#comment-15089000
]
ASF GitHub Bot commented on JENA-1083:
--------------------------------------
Github user afs commented on a diff in the pull request:
https://github.com/apache/jena/pull/120#discussion_r49173681
--- Diff:
jena-arq/src/main/java/org/apache/jena/sparql/core/mem/PMapQuadTable.java ---
@@ -37,13 +39,29 @@
* use.
*
*/
-public abstract class PMapQuadTable extends PMapTupleTable<FourTupleMap,
Quad>implements QuadTable {
+public class PMapQuadTable extends PMapTupleTable<FourTupleMap, Quad,
Consumer4<Node>>implements QuadTable {
+
+
+ private static class QuadTupleMap extends TupleMap {
+
+ private QuadTupleMap(final String mappedOrder) {
+ super(mappedOrder, compileMapping("GSPO", mappedOrder));
+ }
+ }
+
--- End diff --
I don't see the point of this class (ditto`TripleTupleMap`).
`QuadTupleMap` is passed to the constructor `PMapTupleTable` as a
`TupleMap`. A static function will do the same for the `PMapTupleTable`
constructor.
```
private static Tuplemap makeTupleMap(String mappedOrder)
{ return TupleMap.create("GSPO", mappedOrder) ; }
```
and
```
public PMapQuadTable(final String order) {
this(order, makeTupleMap(order));
}
```
More of a style point but I would make the code general and not hard-code
GSPO into the index code. Instead pass in a a pair when the index is made.
with calls like """make index("GSPO", "SPOG")""". Then changes to idnexing are
all in one place.
> 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)
