Perhaps an EnumSet and a single method:
EnumSet<AccessMode> getAccessModes();
Assuming you can do bitwise operators on enum members in Java:
enum AccessMode {
Read,
Append,
Delete
};
So a Read/Write graph returns:
EnumSet.of(AccessMode.Read, AccessMode.Append, AccessMode.Delete);
A read only graph returns:
EnumSet.of(AccessMode.Read);
An append only graph returns:
EnumSet.of(AccessMode.Append);
etc.
Rob
On 30/04/2015 21:55, "Andy Seaborne" <[email protected]> wrote:
>On 30/04/15 21:33, Claude Warren wrote:
>> So if a graph allows adding but not deleting how does it respond to the
>> isReadOnly() method?
>
>My question was how important/frequent is that case vs the importance of
>the question "is this graph mutable"? If it is rare, then designing
>around the uncommon cases to disadvantage the common leads to a
>confusing design.
>
>isReadOnly() is false is the graph can change in any way.
>Of course, we could have a default method in Graph that is
>
> default boolean isReadOnly()
> { return !addAllowed() && !deleteAllowed() ; }
>
>but a proliferation of methods isn't helpful either.
>
> Andy
>
>>
>>
>>
>> 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.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>
