On 10/05/13 14:32, Ian Dickinson wrote:
On 10/05/13 11:46, Andy Seaborne wrote:
Then the JENA-450 report came in. JENA-450 is the problem that code
can't create OntModels inside read transactions when the model is new --
it tries to set prefixes and read-only really is read-only.
The OntModelImpl constructor copies in prefixes from the profile. If
the model is new, the prefixes aren't defined in the model, and the code
sets them. But it can't.
A couple of possible fixes:
1/ Put try{} around the setNsPrefix loop and skip if an exception occurs.
2/ Always have an updatable in-memory prefix mapping for read-only model.
(2) seems better but I'm not absolutely sure how to achieve it yet
within the current mechanism.
It would be so, so much better if a prefix mapping was a thing that a
model had by composition, rather than a thing that a model subclassed.
That might be a good change to think about making in future. I've never
liked the current setup :)
Is there a way of telling whether a model is read-only, other than
trying a write and catching the exception?
No - there is Capabilities on graphs but as far as I know, nothing uses
them. looks like the app can't get to them via the model any way. They
don't provide a clear cut can/can't - they provide "can perform" on
variations of add and delete.
The only uses I can find are:
1/ sizeAccurate() the isomorphism matcher.
2/ findContractSafe() in teh RDF/XML-ABBREV writer - I have no idea what
"safe" means.
/**
Answer true if the find() contract on the associated graph
is "safe", ie, can be used safely by the pretty-printer (we'll
tighten up that definition).
*/
An alternative behaviour-altering change would be to remove the default
prefixes from OntModel altogether, hence no need to do any updates in
the constructor. OntModel is the only model that does set default
prefixes, and the ones it sets are rdf:, rdfs:, owl: and xsd:. One could
argue that there's utility in those being available in all models by
default, in which case it could be a read-only extension to the base
mapping.
How about adding that to JENA-189 (Jena3 collecting)?
Long term, beyond 2.10.1, changing the design of TDB graphs to have
graphs work across transaction boundaries looks like the right thing to
do. The graph also carries around internal details used by the query
execution engine. Then model.begin/model.commit can work as a write
transaction. Not the sort of thing to do just before a release after
people have tested for us.
For this release, I suggest a short amount of time to see if there is
some temporary fix for JENA-450 (e.g. 1), then do the release
regardless. This isn't a regression; it does need fixing; there are
many other things in 2.10.1 that are better than 2.10.0.
I can do that if you'd like me to.
Great - we might as well do (1) (try-catch on setNSPrefix) anyway and
(2) if it also works. No cost in having both.
Ian
Andy
