[
https://issues.apache.org/jira/browse/JENA-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15052528#comment-15052528
]
ASF GitHub Bot commented on JENA-1083:
--------------------------------------
Github user afs commented on a diff in the pull request:
https://github.com/apache/jena/pull/106#discussion_r47336271
--- Diff:
jena-arq/src/main/java/org/apache/jena/sparql/core/mem/QuadTableForm.java ---
@@ -124,31 +96,21 @@ public PMapQuadTable get() {
return new PMapQuadTable(name()) {
@Override
- protected Quad quad(final Node s, final Node p,
final Node o, final Node g) {
- return Quad.create(g, s, p, o);
- }
+ public Quad tuple(final Quad q) {
+ return create(q.getSubject(), q.getPredicate(),
q.getObject(), q.getGraph());
--- End diff --
It'll be clear when the white space is standardised but am I right in
seeing:
* Using Quad and putting strange things in the slots which is very
confusing. `getGraph` returns the `getSubject`.
* There seems to be some creating objects just to take them apart again.
The strength of the design is that quads/triples are not stored, instead nodes
are placed in indexes. To reflect that, operations based on g/s/p/o in some
order are clearer to me at least as well as reducing object churn.
> 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)
