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? --- 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
