(Tying threads together ...)
This PR does not cover:
handlesLiteralTyping()
I'd like to set this on the path to removal mainly because it is unclear
and limiting. It really means "whatever GraphMem" does. It gets
complicated when graph are combined (e.g. union of with and without this
capability) or other composed forms (e.g. inference). I haven't found
code that correctly does that, whatever "correctly" might mean.
Once, there was a clear distinction between GraphMem, with index values
and database backed graph (indexed terms only). This is no longer true.
We have a variety: in-memory, term only (TIM); disk-backed, some
values, looses duplicate values (TDB); as well as GraphMem (value
indexed, does not loose duplicate values).
All make sense.
So how about removing value-related testing the contract of Graph?
The contract tested on Graph is RDF 1.1 -- term equality.
(Values look like some kind of entailment anyway).
Andy
------------------
https://github.com/apache/jena/pull/200
JENA-1270: Deprecate some methods of Capabilities
This PR deprecates the following interface methods
- `addAllowed( everyTriple )`
- `deleteAllowed( everyTriple )`
- `iteratorRemoveAllowed()`
- `canBeEmpty()`
- `findContractSafe()`
------------------
On 11/12/16 20:17, Claude Warren wrote:
I think that the permissions layer sets
boolean addAllowed( boolean everyTriple );
and
boolean deleteAllowed( boolean everyTriple );
But does not use them directly.
I often wondered what the findContractSafe was.
boolean iteratorRemoveAllowed(); -- not sure of the value here seems like
most code will attempt the remove and then catch any error.
boolean canBeEmpty(); -- This is used by the contract testing, however it
could be moved to the graph producer since it is required for the tests.
boolean handlesLiteralTyping(); -- Not sure about the usefulness of this
method. If the graph does not do literal typing does it change the way the
higher levels need to work?
Claude
On Sun, Dec 11, 2016 at 6:30 PM, Andy Seaborne <[email protected]> wrote:
Looking at the Capabilities methods, I think there can be some
simplification.
I also pretty sure no applications actually use the capabilities features
but I'm just picking out the safest route in this proposal. Note that
GraphReadOnly does
Often, the meaning depends on the combination of graphs so for example
"iteratorRemoveAllowed" all depends. So it is not reliable.
boolean iteratorRemoveAllowed();
boolean canBeEmpty();
boolean handlesLiteralTyping();
This is purely internal:
boolean findContractSafe()
has one use, for bugs that were resolved(?) pre-Apache according to the
comment. I don't know what the contract is. It is used by InfGraph. There
is a test but I don't know what it is testing for.
PrettyWriterTest.test803804 - it just seems to test that the Abbrev graph
response it to and not the root cause.
Not used as far as I can determine:
boolean addAllowed( boolean everyTriple );
This is used by InfGraphs:
boolean deleteAllowed( boolean everyTriple );
though I can't find out what it means. I pretty sure no app uses it (what
would it do in response to "false"?)
These seem reasonable or are in-use:
boolean addAllowed();
boolean deleteAllowed();
boolean sizeAccuruate();
Proposal:
deprecate prior to removal:
boolean iteratorRemoveAllowed();
boolean canBeEmpty();
boolean handlesLiteralTyping();
boolean addAllowed( boolean everyTriple );
boolean deleteAllowed( boolean everyTriple );
Andy
From before:
https://lists.apache.org/thread.html/6d26dd787e5678aa3a9b1f1
7194f44a7204425c0f51667d54f8d6bf7@1378035422@%3Cdev.jena.apache.org%3E
