You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Andy Seaborne <an...@apache.org> on 2013/05/07 15:45:58 UTC
Re: Jena 2.10.1 - time to start the cycle?
So far, so good.
There have been some useful reports, including SDB, and some
fixes/additions:
+ Added improved Fuseki start script
+ OpAsQuery fix rewriting nested selects
+ Optimizer improvement for DISTINCT and ORDER BY
+ Serializing queries for SERVICE: property paths could break the syntax.
+ One significant fix to RIOT in the handling file: URIs mostly
affecting Windows
+ Query timeouts now work as advertised
JENA-447 is SDB related but it's not a regression as far as I can see.
(Seems to be something with concurrent, transactions and the bulk loader.)
Andy
Re: Jena 2.10.1 - time to start the cycle?
Posted by Andy Seaborne <an...@apache.org>.
OK - release for 2.10.1 has been set in progress.
I'm still planning on doing a co-ordinated SDB release but that may take
a bit of sorting out. In theory, multiple builds per stagign repo are
possible but I haven't tested how that interacts with the mvn release
plugin.
Rather than delay 2.10.1, I've done the 2.10.1 now. SDB can follow
shortly (it is the same amount of checking needed).
Again - kudos to Rob's instructions - including recovery from svn mirror
lack-of-sync.
Andy
Re: Jena 2.10.1 - time to start the cycle?
Posted by Andy Seaborne <an...@apache.org>.
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
Re: Jena 2.10.1 - time to start the cycle?
Posted by Ian Dickinson <ia...@epimorphics.com>.
On 10/05/13 11:46, Andy Seaborne wrote:
> The users@ message said "a few weeks" and I was all set to do the
> release ...
>
> 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?
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.
>
> 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.
Ian
Re: Jena 2.10.1 - time to start the cycle?
Posted by Andy Seaborne <an...@apache.org>.
The users@ message said "a few weeks" and I was all set to do the
release ...
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.
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.
Andy
On 08/05/13 03:14, Stephen Owens wrote:
> +1, love to have this version.
>
>
> On Tue, May 7, 2013 at 8:09 PM, Rob Vesse <rv...@yarcdata.com> wrote:
>
>> Yes things look good, I don't think I have anything else that I need/want
>> to get into the release
>>
>> Rob
>>
>>
>>
>> On 5/7/13 6:45 AM, "Andy Seaborne" <an...@apache.org> wrote:
>>
>>> So far, so good.
>>>
>>> There have been some useful reports, including SDB, and some
>>> fixes/additions:
>>>
>>> + Added improved Fuseki start script
>>>
>>> + OpAsQuery fix rewriting nested selects
>>>
>>> + Optimizer improvement for DISTINCT and ORDER BY
>>>
>>> + Serializing queries for SERVICE: property paths could break the syntax.
>>>
>>> + One significant fix to RIOT in the handling file: URIs mostly
>>> affecting Windows
>>>
>>> + Query timeouts now work as advertised
>>>
>>>
>>> JENA-447 is SDB related but it's not a regression as far as I can see.
>>> (Seems to be something with concurrent, transactions and the bulk loader.)
>>>
>>> Andy
>>>
>>
>>
>
>
Re: Jena 2.10.1 - time to start the cycle?
Posted by Stephen Owens <st...@thoughtwire.ca>.
+1, love to have this version.
On Tue, May 7, 2013 at 8:09 PM, Rob Vesse <rv...@yarcdata.com> wrote:
> Yes things look good, I don't think I have anything else that I need/want
> to get into the release
>
> Rob
>
>
>
> On 5/7/13 6:45 AM, "Andy Seaborne" <an...@apache.org> wrote:
>
> >So far, so good.
> >
> >There have been some useful reports, including SDB, and some
> >fixes/additions:
> >
> >+ Added improved Fuseki start script
> >
> >+ OpAsQuery fix rewriting nested selects
> >
> >+ Optimizer improvement for DISTINCT and ORDER BY
> >
> >+ Serializing queries for SERVICE: property paths could break the syntax.
> >
> >+ One significant fix to RIOT in the handling file: URIs mostly
> >affecting Windows
> >
> >+ Query timeouts now work as advertised
> >
> >
> >JENA-447 is SDB related but it's not a regression as far as I can see.
> >(Seems to be something with concurrent, transactions and the bulk loader.)
> >
> > Andy
> >
>
>
--
Regards,
*
*
*Stephen Owens*
CTO, ThoughtWire
t 647.351.9473 ext.104 I m 416.697.3466
Re: Jena 2.10.1 - time to start the cycle?
Posted by Rob Vesse <rv...@yarcdata.com>.
Yes things look good, I don't think I have anything else that I need/want
to get into the release
Rob
On 5/7/13 6:45 AM, "Andy Seaborne" <an...@apache.org> wrote:
>So far, so good.
>
>There have been some useful reports, including SDB, and some
>fixes/additions:
>
>+ Added improved Fuseki start script
>
>+ OpAsQuery fix rewriting nested selects
>
>+ Optimizer improvement for DISTINCT and ORDER BY
>
>+ Serializing queries for SERVICE: property paths could break the syntax.
>
>+ One significant fix to RIOT in the handling file: URIs mostly
>affecting Windows
>
>+ Query timeouts now work as advertised
>
>
>JENA-447 is SDB related but it's not a regression as far as I can see.
>(Seems to be something with concurrent, transactions and the bulk loader.)
>
> Andy
>