So if a graph allows adding but not deleting how does it respond to the isReadOnly() method?
On Thu, Apr 30, 2015 at 9:13 PM, Andy Seaborne <[email protected]> wrote: > On 29/04/15 20:58, Andy Seaborne wrote: > >> On 29/04/15 18:17, Claude Warren wrote: >> >>> 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. >>> >> >> When is this ever false? Inference graphs? >> >> (This is not used in the current codebase as far as I can see) >> >> deleteAllowd() same use as addAllowed() >>> iteratorRemoveAllowed() -- this is handy to know before the remove is >>> attempted. >>> >> >> This isn't honoured everywhere IIRC. You're only looking in jena-core. >> >> 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. >>> >> >> FYI: >> https://github.com/afs/quack >> >> 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. >>> >> >> and presumably not addAllowed(boolean), deleteAllowed(boolean) >> >> (I find the boolean form unhelpful because they don't say what triples >> can and can not be add/deleted.) >> >> so let's try removing: >> >> addAllowed(boolean) >> deleteAllowed(boolean) >> findContractSafe() >> handlesLiteralTyping() >> > > which leaves: > > boolean sizeAccurate(); > boolean addAllowed(); > boolean deleteAllowed(); > boolean iteratorRemoveAllowed(); > boolean canBeEmpty(); > > Is it better to have > > isReadOnly() > > and not addAllowed(), deleteAllowed() > > I can imagine append-only graphs but is it worth having two calls when the > common case is read-only vs writable. > > And if it is just > > boolean sizeAccurate(); > boolean isReadOnly(); > boolean iteratorRemoveAllowed(); > boolean canBeEmpty(); > > Should we just pull these up into Graph/GraphBase? > > I have only found two uses of Capabilities in non-test, non-passing-on > cases. I didn't find any evidence of passing capabilities around. > > One use of getCapabilities() in the isomorphism tester GraphMatcher - it > needs sizeAccurate()). > > One use in RDF/XML output; Abbreviated uses findContractSafe but it prints > a warning if used and no one has asked about that in a long while so I'm > guessing it does not happen any more. > > Strangely - I can't find uses of iteratorRemoveAllowed() except in tests. > > Andy > > > >> Andy >> >> >>> 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
