[
https://issues.apache.org/jira/browse/JENA-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15002274#comment-15002274
]
ASF GitHub Bot commented on JENA-624:
-------------------------------------
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/94#issuecomment-156145087
I'm not quite sure what you mean by "`TestDatasetGraphInMemory` and
`TestInMemory` seem to both call `TestDatasetGraphInMemory`" It doesn't seem to
be calling itself when I read the code... `TestDatasetGraphInMemory` itself is
just a container for the things inside it, which all together form the tests
for the one class `DatasetGraphInMemory`. It runs using the suite runner to
operate all the tests inside it, and it definitely gets called by
`TestInMemory`, which itself gets linked up into `TS_Core`.
I think I need to rename `TestInMemory` to `TS_InMemory` to come into line
with the naming convention, right? It is responsible for testing all the
machinery that together is self to implement the new in-memory dataset design,
several different classes, not just `DatasetGraphInMemory` itself.
I can definitely break the various things in `TestDatasetGraphInMemory`
out, but given that it is currently only about 250 lines, most of which is Java
formatting and boilerplate, and that most of those nested guys are just trivial
subtypes of abstract dataset test classes from elsewhere, I thought it might
actually be _harder_ to read broken out. In a different language, I might use
multiple concrete inheritance to clarify/simplify this, letting
`TestDatasetGraphInMemory` inherit from all these various abstract test classes
directly. But I'm fine either way.
Shall I make another commit renaming `TestInMemory` to `TS_InMemory` and
breaking apart `TestDatasetGraphInMemory` to a `TS_DatasetGraphInMemory` and
multiple classes like `TestDatasetGraphInMemoryThreading`,
`TestDatasetGraphInMemoryLock`, etc.?
> Develop a new in-memory RDF Dataset implementation
> --------------------------------------------------
>
> Key: JENA-624
> URL: https://issues.apache.org/jira/browse/JENA-624
> Project: Apache Jena
> Issue Type: Improvement
> Reporter: Andy Seaborne
> Assignee: A. Soroka
> Labels: gsoc, gsoc2015, java, linked_data, rdf
>
> The current (Jan 2014) Jena in-memory dataset uses a general purpose
> container that works for any storage technology for graphs together with
> in-memory graphs.
> This project would develop a new implementation design specifically for RDF
> datasets (triples and quads) and efficient SPARQL execution, for example,
> using multi-core parallel operations and/or multi-version concurrent
> datastructures to maximise true parallel operation.
> This is a system project suitable for someone interested in datatbase
> implementation, datastructure design and implementation, operating systems or
> distributed systems.
> Note that TDB can operate in-memory using a simulated disk with
> copy-in/copy-out semantics for disk-level operations. It is for faithful
> testing TDB infrastructure and is not designed performance, general in-memory
> use or use at scale. While lesson may be learnt from that system, TDB
> in-memory is not the answer here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
