On 30/04/15 07:20, Claude Warren wrote:
While we are at it I would like to see that restriction that requires
Grahp.getStatisticsHandler() to return the same instance every time
removed. It makes proxies much more difficult.
Makes sense.
(I would note that statistics for anything involving 2 out of 3 of the
args are not provided by any graph that I can find).
Andy
On Wed, Apr 29, 2015 at 8:58 PM, Andy Seaborne <[email protected]> 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()
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.
