I use the following: addAllowed() is used by contract tests to determine if triples can be added. Also, permission system sets this based on the users permissions. canBeEmpty() is used by the contract tests to determine if the deleteAll methods should return an empty graph. deleteAllowd() same use as addAllowed() iteratorRemoveAllowed() -- this is handy to know before the remove is attempted. sizeAccurate() -- this is used by the contract testing to determine if delete and add should alter the number of records reported. I am also looking at adding some hash joining capabilities and knowing if the sizes are accurate may make a difference. But that is all future stuff.
These I don't use and can see being removed: findContractSafe() -- I don't know what this one means and have never used it. handlesLiteralTyping() -- This was used but obviously sine all graphs now have to support literal typing this can be removed. On Wed, Apr 29, 2015 at 4:14 PM, Andy Seaborne <[email protected]> wrote: > On 29/04/15 16:04, Claude Warren wrote: > >> I have no problem retiring FileGraph >> >> Capabilities is another issue. I have used it and it is used in several >> places in the contract tests where we have to know if the graph supports >> transactions and the like. I find it useful. In addtion the information >> containd in the capabilities is often not easily discoverable (if at all). >> >> > Transactions aren't in the Capabilities interface. > > Which aspects of the Capabilities interface? Some looks to be out of date > (findContractSafe); some are not the right question (handlesLiteralTyping) > > Andy > > > >> >> On Wed, Apr 29, 2015 at 9:45 AM, Andy Seaborne <[email protected]> wrote: >> >> Claude's email about FileGraph prompted me to think for Jena3: >>> >>> What can be removed? >>> What can be simplifed? >>> >>> Even while keeping the current APIs, there is going to stuff that isn't >>> used, isn't used much, or even gets in the way. For maintainability, >>> effectively unused features are noise and risk needing to maintain >>> contracts that users don't actually use. >>> >>> Some things that come to mind in jena-core: >>> >>> FileGraph [*] >>> Capabilities >>> GraphTransactionHandler >>> >>> and with advocacy: >>> >>> RDFReaderF, RDFWriterF (with RIOT integration; caution for RDF/XML) >>> >>> Some places where interfaces don't seem to add anything: >>> >>> LiteralLabelImpl >>> >>> (actually the whole LiteralLabel thing is worth looking at - maybe we can >>> pull the whole thing into into Node_Literal itself) >>> >>> AnonIds - maybe leave in the RDFAPI (they cross the boundary) but >>> internall bNodes can be a couple of longs for their state (a UUID in >>> other >>> words, not a UID). >>> >>> Andy >>> >>> [*] >>> In Java8, the app, or library code, could do this better as: >>> >>> update(()->{ >>> ... graph changes ... >>> } >>> >>> and update() does the on-disk backup stuff. >>> >>> >> >> >> > -- I like: Like Like - The likeliest place on the web <http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
