On 10/12/15 13:31, A. Soroka wrote:
To the first question, I think the answer is yes. It was very much my intention
that TupleTable and its subtypes would provide opportunity to explore different
useful structures (e.g. Claude Warren’s ideas about Bloom filters). A
[Triple|Quad]Table that uses ordinary maps/structures in the same way as the
current impl uses persistent structures should be very easy. Would you like me
to cut such classes to have them available for non-transactional cases?
I’m not quite sure what your last sentence means; is it about the semantics of
the factory methods?
There are 4 factory methods in each factory
* DatasetFactory.create()
The new place for in-memory, non-transactional dataset with graph-copy
semantics. Currently, it is a general dataset with "add graph"
overridden to do a copy-in.
* DatasetFactory.createTxnMem()
The new place for in-memory, transactional dataset (with graph-copy
semantics).
* DatasetFactory.createMem()
The old place for in-memory datasets - goes to createGeneral()
Deprecated because if replaced by create() then details have changed.
* DatasetFactory.createGeneral()
The new place for general datasets.
Andy
---
A. Soroka
The University of Virginia Library
On Dec 10, 2015, at 8:15 AM, Andy Seaborne <[email protected]> wrote:
On 09/12/15 21:00, A. Soroka wrote:
Cool. The extension points are basically TripleTable and QuadTable, because of
the constructor DatasetGraphInMemory(QuadTable, TripleTable). Someone could
offer their own impls and use that (public) constructor.
Does that mean it would be easy to do a non-transactional version, that used
hash maps (or used hash maps at the top level at least)?
That would make an excellent performance comparison.
If it makes a difference, it can the implementation for Dataset(Graph)Factory.create()
and have the copy-in semantics for "add graph".
Andy
