Ah, looks nice. The key seems to me to be to abstract over the operation that _requires_ reordering. I have the kind of temperament that tends to ignore the different costs of abstraction in different places. I’ll take a look at using this style in the txn-in-memory dataset, in a way that brings clarity without new costs.
On another note, I’m taking a bash at the “lock-per-named-graph" dataset. Hopefully I’ll have something soonish, that can be run in harness to see if it really offers useful gains in the use cases for which I hope it will. If it works, then maybe it would be worth abstracting to the case of arbitrary partitions of a dataset. Did you want me to look at this: https://issues.apache.org/jira/browse/JENA-1084 ? I was thinking that I should be able to reuse the current TripleStore/TripleBunch machinery underneath the TripleTable and QuadTable interfaces, or possibly just try a very simple ConcurrentHashMap setup. --- A. Soroka The University of Virginia Library > On Dec 31, 2015, at 7:23 AM, Andy Seaborne <[email protected]> wrote: > > Adam, > > I had a go at mapping arguments, all driven by one single TupleMap. > > https://gist.github.com/afs/73f3b118726f1625cb33 > > Andy
