You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Andy Seaborne <an...@apache.org> on 2013/04/25 21:50:51 UTC
Jena 2.10.1 / SDB 1.3.6 -- testing for next release
We'd like to get testing reports on the current Jena development build
over the next few weeks for a release of Jena 2.10.1.
You can get a copy of the development build (via maven dependency or a
download):
http://jena.staging.apache.org/download/index.html#development-builds
There are two areas of special note: Turtle output and query timeouts.
== Turtle output
The writer for Turtle which has been rewritten. The exact output layout
of the Turtle may change.
Full details of using the writing subsystem:
http://jena.staging.apache.org/documentation/io/rdf-output.html
== Query timeouts (including in Fuseki)
Timeouts were not firing in the right places so that often the
time-to-first-row was remaining and behaving as the time-to-last-row.
This is fixed - if you use query timeouts in Fuseki you'll see a
difference in behaviour if you had timeouts going off.
Also The status code from a timeouts query was incorrectly 408 - it's
now 503.
== SDB
At the same time, we'd like to do a separate, coordinated release of SDB
to align the libraries.
But we need help from SDB users in order to get proper testing of SDB.
Please test 1.3.6-SNAPSHOT
(if there aren't enough test reports, we'll have to then see whether a
release of SDB is a good idea or not)
Andy
Re: Jena 2.10.1 / SDB 1.3.6 -- testing for next release
Posted by Andy Seaborne <an...@apache.org>.
On 29/04/13 21:58, Lebling, David (US SSA) wrote:
> Andy,
>
> What is the previous stable release to 2.10.1-SNAPSHOT? I tried upgrading my 2.7.3 to 2.10.0 and have had no success. (I think the issue may be that the transition from openjena to jena was incomplete in 2.10.0?) Is there a 2.9.x release you would recommend as an intermediate step? 2.9.2?
Theer wasn't a 2.9. jena-core went 2.7 -> 2.10, ARQ went 2.9 -> 2.10
>
> My site seems to be unhappy with Apache's use of https: for the snapshot repositories and complains about missing certs.
What a nuisance.
I've copied the latest build (#42) to my ~ space which is http without
bumping up to https.
http://people.apache.org/~andy/jena-sdb-1.3.6-20130427.163903-42-distribution.zip
Andy
>
> Dave
>
RE: Jena 2.10.1 / SDB 1.3.6 -- testing for next release
Posted by "Lebling, David (US SSA)" <da...@baesystems.com>.
Andy,
What is the previous stable release to 2.10.1-SNAPSHOT? I tried upgrading my 2.7.3 to 2.10.0 and have had no success. (I think the issue may be that the transition from openjena to jena was incomplete in 2.10.0?) Is there a 2.9.x release you would recommend as an intermediate step? 2.9.2?
My site seems to be unhappy with Apache's use of https: for the snapshot repositories and complains about missing certs.
Dave
RE: Jena 2.10.1 / SDB 1.3.6 -- testing for next release
Posted by "Lebling, David (US SSA)" <da...@baesystems.com>.
That's exactly correct.
Dave
-----Original Message-----
From: Andy Seaborne [mailto:andy@apache.org]
Sent: Thursday, May 02, 2013 5:00 PM
To: users@jena.apache.org
Subject: Re: Jena 2.10.1 / SDB 1.3.6 -- testing for next release
On 01/05/13 20:11, Andy Seaborne wrote:
> Dave,
>
> I can't recreate this. When you say "does not work" do you mean an
> exception? Or parse error?
I can see how it might happen.
Are you getting an exception from IRIResolver? About an UNWISE_CHARACTER?
Recorded as JENA-448
Andy
>
> I tried this:
>
> public static void main(String... args)
> {
> String fn = "C:\\home\\afs\\D.ttl" ;
> Model m = ModelFactory.createDefaultModel() ;
> FileManager.get().readModel(m, fn) ;
> m.write(System.out, "TTL") ;
> System.out.println("DONE") ;
> }
>
> with a classpath that include jena-arq, jena-core, etc.
> and variations with / and they all seemed to work.
>
> Do you have a complete, standalone example I can try out?
>
> Andy
>
> On 01/05/13 16:00, Lebling, David (US SSA) wrote:
>> I retried all this just to be certain.
>>
>> FileManager.readModel(model, "c:/X/base/sub/file.rdf")
>>
>> i.e., the "cleaned up" filename, does work. The "unclean"
>> ("C:\X\.....") version does not.
>>
>> Apologies for my confusion. Previously I didn't have to clean the
>> filename for it to work; that part of my original message is correct.
>> I -have- always had to clean the filename of the store descriptor
>> file for SDBFactory.connectStore(String file).
>>
>> In the process I also retested with transaction isolation set higher
>> (to Connection.TRANSACTION_REPEATABLE_READ), and the duplicate node
>> error (JENA-447) still happens.
>>
>> I do not use RDFDataMgr (unless something uses it indirectly).
>>
>> Dave
>>
>> -----Original Message-----
>> From: Andy Seaborne [mailto:andy@apache.org]
>> Sent: Wednesday, May 01, 2013 10:00 AM
>> To: users@jena.apache.org
>> Subject: Re: Jena 2.10.1 / SDB 1.3.6 -- testing for next release
>>
>> On 01/05/13 14:41, Lebling, David (US SSA) wrote:
>>> Sorry, I mistyped. It's
>>>
>>> FileManager.readModel(Model model, String filenameOrURI)
>>>
>>> The offending filenames were all Windows style, in fact mixed
>>> slashes and backslashes, such as:
>>>
>>> C:\X\base\sub/file.rdf
>>>
>>> That used to work. Even "cleaning" the filename to:
>>>
>>> c:/X/base/sub/file.rdf
>>>
>>> didn't work.
>>>
>>> I hope this helps.
>>
>> Yes - it gives be something to look it.
>>
>> The code has to special-case C: ... because technically it is a URI,
>> with schema name "C" (oops).
>>
>> Does RDFDataMgr work?
>>
>> Andy
>>
>>
>>>
>>> Dave
>>>
>>> -----Original Message-----
>>> From: Andy Seaborne [mailto:andy@apache.org]
>>> Sent: Wednesday, May 01, 2013 9:01 AM
>>> To: users@jena.apache.org
>>> Subject: Re: Jena 2.10.1 / SDB 1.3.6 -- testing for next release
>>>
>>> On 30/04/13 22:10, Lebling, David (US SSA) wrote:
>>>> Andy,
>>>>
>>>> I was able to get some time today and managed to install and run
>>>> with jena-sdb-1.3.6-SNAPSHOT on top of apache-jena-2.10.1-SNAPSHOT.
>>>>
>>>> I ran a bunch of our integration tests and one of our stress tests
>>>> (not the one that uses the transaction isolation code, yet -- maybe
>>>> tomorrow). All of them ran fine.
>>>>
>>>> The only potential issue I found was that
>>>> FileManager.readModel(String uri, String filenameOrUri) now seems
>>>> to actually require that the second argument be a URI. I was
>>>> running on Windows and before calling the IRI code FileManager
>>>> apparently isn't detecting and converting file names to URIs. It
>>>> may also be that the Javadoc hasn't caught up with a change to the
>>>> readModel contract, if it now requires a URI. I just forced a URI to work around the issue.
>>>>
>>>> Dave
>>>>
>>>
>>> Hi Dave,
>>>
>>> Thanks for the report.
>>>
>>> Which FileManager operation did you mean ?
>>> (there isn't a readModel(String, String))
>>>
>>> FileManager.loadModel(String filenameOrURI, String rdfSyntax)
>>> FileManager.readModel(Model model, String filenameOrURI)
>>> FileManager.readModel(Model model, String filenameOrURI, String
>>> rdfSyntax)
>>>
>>> and they seem to work for me.
>>>
>>> Andy
>>>
>>
>
Re: Jena 2.10.1 / SDB 1.3.6 -- testing for next release
Posted by Andy Seaborne <an...@apache.org>.
On 01/05/13 20:11, Andy Seaborne wrote:
> Dave,
>
> I can't recreate this. When you say "does not work" do you mean an
> exception? Or parse error?
I can see how it might happen.
Are you getting an exception from IRIResolver? About an UNWISE_CHARACTER?
Recorded as JENA-448
Andy
>
> I tried this:
>
> public static void main(String... args)
> {
> String fn = "C:\\home\\afs\\D.ttl" ;
> Model m = ModelFactory.createDefaultModel() ;
> FileManager.get().readModel(m, fn) ;
> m.write(System.out, "TTL") ;
> System.out.println("DONE") ;
> }
>
> with a classpath that include jena-arq, jena-core, etc.
> and variations with / and they all seemed to work.
>
> Do you have a complete, standalone example I can try out?
>
> Andy
>
> On 01/05/13 16:00, Lebling, David (US SSA) wrote:
>> I retried all this just to be certain.
>>
>> FileManager.readModel(model, "c:/X/base/sub/file.rdf")
>>
>> i.e., the "cleaned up" filename, does work. The "unclean"
>> ("C:\X\.....") version does not.
>>
>> Apologies for my confusion. Previously I didn't have to clean the
>> filename for it to work; that part of my original message is correct.
>> I -have- always had to clean the filename of the store descriptor file
>> for SDBFactory.connectStore(String file).
>>
>> In the process I also retested with transaction isolation set higher
>> (to Connection.TRANSACTION_REPEATABLE_READ), and the duplicate node
>> error (JENA-447) still happens.
>>
>> I do not use RDFDataMgr (unless something uses it indirectly).
>>
>> Dave
>>
>> -----Original Message-----
>> From: Andy Seaborne [mailto:andy@apache.org]
>> Sent: Wednesday, May 01, 2013 10:00 AM
>> To: users@jena.apache.org
>> Subject: Re: Jena 2.10.1 / SDB 1.3.6 -- testing for next release
>>
>> On 01/05/13 14:41, Lebling, David (US SSA) wrote:
>>> Sorry, I mistyped. It's
>>>
>>> FileManager.readModel(Model model, String filenameOrURI)
>>>
>>> The offending filenames were all Windows style, in fact mixed slashes
>>> and backslashes, such as:
>>>
>>> C:\X\base\sub/file.rdf
>>>
>>> That used to work. Even "cleaning" the filename to:
>>>
>>> c:/X/base/sub/file.rdf
>>>
>>> didn't work.
>>>
>>> I hope this helps.
>>
>> Yes - it gives be something to look it.
>>
>> The code has to special-case C: ... because technically it is a URI,
>> with schema name "C" (oops).
>>
>> Does RDFDataMgr work?
>>
>> Andy
>>
>>
>>>
>>> Dave
>>>
>>> -----Original Message-----
>>> From: Andy Seaborne [mailto:andy@apache.org]
>>> Sent: Wednesday, May 01, 2013 9:01 AM
>>> To: users@jena.apache.org
>>> Subject: Re: Jena 2.10.1 / SDB 1.3.6 -- testing for next release
>>>
>>> On 30/04/13 22:10, Lebling, David (US SSA) wrote:
>>>> Andy,
>>>>
>>>> I was able to get some time today and managed to install and run with
>>>> jena-sdb-1.3.6-SNAPSHOT on top of apache-jena-2.10.1-SNAPSHOT.
>>>>
>>>> I ran a bunch of our integration tests and one of our stress tests
>>>> (not the one that uses the transaction isolation code, yet -- maybe
>>>> tomorrow). All of them ran fine.
>>>>
>>>> The only potential issue I found was that
>>>> FileManager.readModel(String uri, String filenameOrUri) now seems to
>>>> actually require that the second argument be a URI. I was running on
>>>> Windows and before calling the IRI code FileManager apparently isn't
>>>> detecting and converting file names to URIs. It may also be that the
>>>> Javadoc hasn't caught up with a change to the readModel contract, if
>>>> it now requires a URI. I just forced a URI to work around the issue.
>>>>
>>>> Dave
>>>>
>>>
>>> Hi Dave,
>>>
>>> Thanks for the report.
>>>
>>> Which FileManager operation did you mean ?
>>> (there isn't a readModel(String, String))
>>>
>>> FileManager.loadModel(String filenameOrURI, String rdfSyntax)
>>> FileManager.readModel(Model model, String filenameOrURI)
>>> FileManager.readModel(Model model, String filenameOrURI, String
>>> rdfSyntax)
>>>
>>> and they seem to work for me.
>>>
>>> Andy
>>>
>>
>
Re: Jena 2.10.1 / SDB 1.3.6 -- testing for next release
Posted by Andy Seaborne <an...@apache.org>.
Dave,
I can't recreate this. When you say "does not work" do you mean an
exception? Or parse error?
I tried this:
public static void main(String... args)
{
String fn = "C:\\home\\afs\\D.ttl" ;
Model m = ModelFactory.createDefaultModel() ;
FileManager.get().readModel(m, fn) ;
m.write(System.out, "TTL") ;
System.out.println("DONE") ;
}
with a classpath that include jena-arq, jena-core, etc.
and variations with / and they all seemed to work.
Do you have a complete, standalone example I can try out?
Andy
On 01/05/13 16:00, Lebling, David (US SSA) wrote:
> I retried all this just to be certain.
>
> FileManager.readModel(model, "c:/X/base/sub/file.rdf")
>
> i.e., the "cleaned up" filename, does work. The "unclean" ("C:\X\.....") version does not.
>
> Apologies for my confusion. Previously I didn't have to clean the filename for it to work; that part of my original message is correct. I -have- always had to clean the filename of the store descriptor file for SDBFactory.connectStore(String file).
>
> In the process I also retested with transaction isolation set higher (to Connection.TRANSACTION_REPEATABLE_READ), and the duplicate node error (JENA-447) still happens.
>
> I do not use RDFDataMgr (unless something uses it indirectly).
>
> Dave
>
> -----Original Message-----
> From: Andy Seaborne [mailto:andy@apache.org]
> Sent: Wednesday, May 01, 2013 10:00 AM
> To: users@jena.apache.org
> Subject: Re: Jena 2.10.1 / SDB 1.3.6 -- testing for next release
>
> On 01/05/13 14:41, Lebling, David (US SSA) wrote:
>> Sorry, I mistyped. It's
>>
>> FileManager.readModel(Model model, String filenameOrURI)
>>
>> The offending filenames were all Windows style, in fact mixed slashes and backslashes, such as:
>>
>> C:\X\base\sub/file.rdf
>>
>> That used to work. Even "cleaning" the filename to:
>>
>> c:/X/base/sub/file.rdf
>>
>> didn't work.
>>
>> I hope this helps.
>
> Yes - it gives be something to look it.
>
> The code has to special-case C: ... because technically it is a URI, with schema name "C" (oops).
>
> Does RDFDataMgr work?
>
> Andy
>
>
>>
>> Dave
>>
>> -----Original Message-----
>> From: Andy Seaborne [mailto:andy@apache.org]
>> Sent: Wednesday, May 01, 2013 9:01 AM
>> To: users@jena.apache.org
>> Subject: Re: Jena 2.10.1 / SDB 1.3.6 -- testing for next release
>>
>> On 30/04/13 22:10, Lebling, David (US SSA) wrote:
>>> Andy,
>>>
>>> I was able to get some time today and managed to install and run with
>>> jena-sdb-1.3.6-SNAPSHOT on top of apache-jena-2.10.1-SNAPSHOT.
>>>
>>> I ran a bunch of our integration tests and one of our stress tests
>>> (not the one that uses the transaction isolation code, yet -- maybe
>>> tomorrow). All of them ran fine.
>>>
>>> The only potential issue I found was that
>>> FileManager.readModel(String uri, String filenameOrUri) now seems to
>>> actually require that the second argument be a URI. I was running on
>>> Windows and before calling the IRI code FileManager apparently isn't
>>> detecting and converting file names to URIs. It may also be that the
>>> Javadoc hasn't caught up with a change to the readModel contract, if
>>> it now requires a URI. I just forced a URI to work around the issue.
>>>
>>> Dave
>>>
>>
>> Hi Dave,
>>
>> Thanks for the report.
>>
>> Which FileManager operation did you mean ?
>> (there isn't a readModel(String, String))
>>
>> FileManager.loadModel(String filenameOrURI, String rdfSyntax)
>> FileManager.readModel(Model model, String filenameOrURI)
>> FileManager.readModel(Model model, String filenameOrURI, String
>> rdfSyntax)
>>
>> and they seem to work for me.
>>
>> Andy
>>
>
RE: Jena 2.10.1 / SDB 1.3.6 -- testing for next release
Posted by "Lebling, David (US SSA)" <da...@baesystems.com>.
I retried all this just to be certain.
FileManager.readModel(model, "c:/X/base/sub/file.rdf")
i.e., the "cleaned up" filename, does work. The "unclean" ("C:\X\.....") version does not.
Apologies for my confusion. Previously I didn't have to clean the filename for it to work; that part of my original message is correct. I -have- always had to clean the filename of the store descriptor file for SDBFactory.connectStore(String file).
In the process I also retested with transaction isolation set higher (to Connection.TRANSACTION_REPEATABLE_READ), and the duplicate node error (JENA-447) still happens.
I do not use RDFDataMgr (unless something uses it indirectly).
Dave
-----Original Message-----
From: Andy Seaborne [mailto:andy@apache.org]
Sent: Wednesday, May 01, 2013 10:00 AM
To: users@jena.apache.org
Subject: Re: Jena 2.10.1 / SDB 1.3.6 -- testing for next release
On 01/05/13 14:41, Lebling, David (US SSA) wrote:
> Sorry, I mistyped. It's
>
> FileManager.readModel(Model model, String filenameOrURI)
>
> The offending filenames were all Windows style, in fact mixed slashes and backslashes, such as:
>
> C:\X\base\sub/file.rdf
>
> That used to work. Even "cleaning" the filename to:
>
> c:/X/base/sub/file.rdf
>
> didn't work.
>
> I hope this helps.
Yes - it gives be something to look it.
The code has to special-case C: ... because technically it is a URI, with schema name "C" (oops).
Does RDFDataMgr work?
Andy
>
> Dave
>
> -----Original Message-----
> From: Andy Seaborne [mailto:andy@apache.org]
> Sent: Wednesday, May 01, 2013 9:01 AM
> To: users@jena.apache.org
> Subject: Re: Jena 2.10.1 / SDB 1.3.6 -- testing for next release
>
> On 30/04/13 22:10, Lebling, David (US SSA) wrote:
>> Andy,
>>
>> I was able to get some time today and managed to install and run with
>> jena-sdb-1.3.6-SNAPSHOT on top of apache-jena-2.10.1-SNAPSHOT.
>>
>> I ran a bunch of our integration tests and one of our stress tests
>> (not the one that uses the transaction isolation code, yet -- maybe
>> tomorrow). All of them ran fine.
>>
>> The only potential issue I found was that
>> FileManager.readModel(String uri, String filenameOrUri) now seems to
>> actually require that the second argument be a URI. I was running on
>> Windows and before calling the IRI code FileManager apparently isn't
>> detecting and converting file names to URIs. It may also be that the
>> Javadoc hasn't caught up with a change to the readModel contract, if
>> it now requires a URI. I just forced a URI to work around the issue.
>>
>> Dave
>>
>
> Hi Dave,
>
> Thanks for the report.
>
> Which FileManager operation did you mean ?
> (there isn't a readModel(String, String))
>
> FileManager.loadModel(String filenameOrURI, String rdfSyntax)
> FileManager.readModel(Model model, String filenameOrURI)
> FileManager.readModel(Model model, String filenameOrURI, String
> rdfSyntax)
>
> and they seem to work for me.
>
> Andy
>
Re: Jena 2.10.1 / SDB 1.3.6 -- testing for next release
Posted by Andy Seaborne <an...@apache.org>.
On 01/05/13 14:41, Lebling, David (US SSA) wrote:
> Sorry, I mistyped. It's
>
> FileManager.readModel(Model model, String filenameOrURI)
>
> The offending filenames were all Windows style, in fact mixed slashes and backslashes, such as:
>
> C:\X\base\sub/file.rdf
>
> That used to work. Even "cleaning" the filename to:
>
> c:/X/base/sub/file.rdf
>
> didn't work.
>
> I hope this helps.
Yes - it gives be something to look it.
The code has to special-case C: ... because technically it is a URI,
with schema name "C" (oops).
Does RDFDataMgr work?
Andy
>
> Dave
>
> -----Original Message-----
> From: Andy Seaborne [mailto:andy@apache.org]
> Sent: Wednesday, May 01, 2013 9:01 AM
> To: users@jena.apache.org
> Subject: Re: Jena 2.10.1 / SDB 1.3.6 -- testing for next release
>
> On 30/04/13 22:10, Lebling, David (US SSA) wrote:
>> Andy,
>>
>> I was able to get some time today and managed to install and run with
>> jena-sdb-1.3.6-SNAPSHOT on top of apache-jena-2.10.1-SNAPSHOT.
>>
>> I ran a bunch of our integration tests and one of our stress tests
>> (not the one that uses the transaction isolation code, yet -- maybe
>> tomorrow). All of them ran fine.
>>
>> The only potential issue I found was that FileManager.readModel(String
>> uri, String filenameOrUri) now seems to actually require that the
>> second argument be a URI. I was running on Windows and before calling
>> the IRI code FileManager apparently isn't detecting and converting
>> file names to URIs. It may also be that the Javadoc hasn't caught up
>> with a change to the readModel contract, if it now requires a URI. I
>> just forced a URI to work around the issue.
>>
>> Dave
>>
>
> Hi Dave,
>
> Thanks for the report.
>
> Which FileManager operation did you mean ?
> (there isn't a readModel(String, String))
>
> FileManager.loadModel(String filenameOrURI, String rdfSyntax) FileManager.readModel(Model model, String filenameOrURI) FileManager.readModel(Model model, String filenameOrURI, String rdfSyntax)
>
> and they seem to work for me.
>
> Andy
>
RE: Jena 2.10.1 / SDB 1.3.6 -- testing for next release
Posted by "Lebling, David (US SSA)" <da...@baesystems.com>.
Sorry, I mistyped. It's
FileManager.readModel(Model model, String filenameOrURI)
The offending filenames were all Windows style, in fact mixed slashes and backslashes, such as:
C:\X\base\sub/file.rdf
That used to work. Even "cleaning" the filename to:
c:/X/base/sub/file.rdf
didn't work.
I hope this helps.
Dave
-----Original Message-----
From: Andy Seaborne [mailto:andy@apache.org]
Sent: Wednesday, May 01, 2013 9:01 AM
To: users@jena.apache.org
Subject: Re: Jena 2.10.1 / SDB 1.3.6 -- testing for next release
On 30/04/13 22:10, Lebling, David (US SSA) wrote:
> Andy,
>
> I was able to get some time today and managed to install and run with
> jena-sdb-1.3.6-SNAPSHOT on top of apache-jena-2.10.1-SNAPSHOT.
>
> I ran a bunch of our integration tests and one of our stress tests
> (not the one that uses the transaction isolation code, yet -- maybe
> tomorrow). All of them ran fine.
>
> The only potential issue I found was that FileManager.readModel(String
> uri, String filenameOrUri) now seems to actually require that the
> second argument be a URI. I was running on Windows and before calling
> the IRI code FileManager apparently isn't detecting and converting
> file names to URIs. It may also be that the Javadoc hasn't caught up
> with a change to the readModel contract, if it now requires a URI. I
> just forced a URI to work around the issue.
>
> Dave
>
Hi Dave,
Thanks for the report.
Which FileManager operation did you mean ?
(there isn't a readModel(String, String))
FileManager.loadModel(String filenameOrURI, String rdfSyntax) FileManager.readModel(Model model, String filenameOrURI) FileManager.readModel(Model model, String filenameOrURI, String rdfSyntax)
and they seem to work for me.
Andy
Re: Jena 2.10.1 / SDB 1.3.6 -- testing for next release
Posted by Andy Seaborne <an...@apache.org>.
On 30/04/13 22:10, Lebling, David (US SSA) wrote:
> Andy,
>
> I was able to get some time today and managed to install and run with
> jena-sdb-1.3.6-SNAPSHOT on top of apache-jena-2.10.1-SNAPSHOT.
>
> I ran a bunch of our integration tests and one of our stress tests
> (not the one that uses the transaction isolation code, yet -- maybe
> tomorrow). All of them ran fine.
>
> The only potential issue I found was that
> FileManager.readModel(String uri, String filenameOrUri) now seems to
> actually require that the second argument be a URI. I was running on
> Windows and before calling the IRI code FileManager apparently isn't
> detecting and converting file names to URIs. It may also be that the
> Javadoc hasn't caught up with a change to the readModel contract, if
> it now requires a URI. I just forced a URI to work around the issue.
>
> Dave
>
Hi Dave,
Thanks for the report.
Which FileManager operation did you mean ?
(there isn't a readModel(String, String))
FileManager.loadModel(String filenameOrURI, String rdfSyntax)
FileManager.readModel(Model model, String filenameOrURI)
FileManager.readModel(Model model, String filenameOrURI, String rdfSyntax)
and they seem to work for me.
Andy
RE: Jena 2.10.1 / SDB 1.3.6 -- testing for next release
Posted by "Lebling, David (US SSA)" <da...@baesystems.com>.
Andy,
I was able to get some time today and managed to install and run with jena-sdb-1.3.6-SNAPSHOT on top of apache-jena-2.10.1-SNAPSHOT.
I ran a bunch of our integration tests and one of our stress tests (not the one that uses the transaction isolation code, yet -- maybe tomorrow). All of them ran fine.
The only potential issue I found was that FileManager.readModel(String uri, String filenameOrUri) now seems to actually require that the second argument be a URI. I was running on Windows and before calling the IRI code FileManager apparently isn't detecting and converting file names to URIs. It may also be that the Javadoc hasn't caught up with a change to the readModel contract, if it now requires a URI. I just forced a URI to work around the issue.
Dave
Re: Jena 2.10.1 / SDB 1.3.6 -- testing for next release
Posted by Andy Seaborne <an...@apache.org>.
On 29/04/13 12:38, Lebling, David (US SSA) wrote:
> Andy,
>
>> The ClassNotFound is just some internal reorganisation to improve
>> the modularity of the code base. That's why I'd prefer not to let
>> SDB get too out of sync with the main releases.
>
> I can understand that. The exact problem has to do with other
> third-party code we are using and cannot update to a newer version.
> In the end there is a tangle of four different versions of xercesImpl
> that ends up with the wrong one being loaded for SDB (or possibly
> Jena itself, since the dependency is IIRC in your parent POM).
Always a problem.
Despite having to name an explicit version, Jena is not actually
particularly sensitive to the Xerces version anymore at least to within
a few minor versions. Jena does call into Xerces "internals" but they
are so widely used they are a de facto API nowadays.
Or you can download the source and rebuild with a different Xerces
version and see if it works.
Similarly, using a newer version of Xerces other packages is often worth
ago if you can.
>
>> Was there a JIRA raised for the "duplicate node" error?
>
> You posted on 4/17 some ruminations on the cause, etc. I did not
> raise a JIRA, so if you didn't my guess is there isn't one.
Could you raise a JIRA please?
Andy
>
>> Seeing that error message makes it a bit clearer to me. It's
>> something to do with the bulk loader (NNodeQuads1740763164) and
>> some othe raction has already inserted a node. As the possible
>> values for a row in the node table are fixed for a given primary
>> key, I wonder if it's possible to insert but ignore duplicates
>> (which won't an a different duplicate). And maybe the LOCK TABLE
>> needs to be further out. (/me hopes Damian has better insight
>> here)
>>
>> WARN [tomcat-http--10] (SDBConnection.java:338) - execUpdate:
>> SQLException ERROR: duplicate key value violates unique constraint
>> "nodes_pkey" Detail: Key (hash)=(-8555076428185164481) already
>> exists. LOCK TABLE Nodes; INSERT INTO Nodes (hash, lex, lang,
>> datatype, type) SELECT NNodeQuads1740763164.n0 ,
>> NNodeQuads1740763164.n1 , NNodeQuads1740763164.n2 ,
>> NNodeQuads1740763164.n3 , NNodeQuads1740763164.n4 FROM
>> NNodeQuads1740763164 LEFT JOIN Nodes ON
>> (NNodeQuads1740763164.n0=Nodes.hash) WHERE Nodes.hash IS NULL
>>
>> Andy
>
> -----Original Message----- From: Andy Seaborne
> [mailto:andy@apache.org]main Sent: Friday, April 26, 2013 6:12 AM To:
> users@jena.apache.org Subject: Re: Jena 2.10.1 / SDB 1.3.6 -- testing
> for next release
>
> On 25/04/13 22:04, Lebling, David (US SSA) wrote:
>> Andy,
>>
>> I'd love to be able to test SDB 1.3.6 but we are not able to update
>> to Jena 2.10.1 for reasons too tedious to go into here, and trying
>> to use this SDB with an older version of Jena (*cough* 2.7.3
>> *cough)
>
> Cough and splutter.
>
>> doesn't seem to work, probably not to your surprise. The exact
>> exception is: "Caused by: java.lang.ClassNotFoundException:
>> org.apache.jena.atlas.lib.Lib". SDB 1.3.5 worked fine in that
>> environment, aside from the SDB "duplicate node" error I reported
>> earlier.
>
>
>>
>> Dave Lebling
>>
>> -----Original Message----- From: Andy Seaborne
>> [mailto:andy@apache.org] Sent: Thursday, April 25, 2013 3:51 PM
>> To: users@jena.apache.org Subject: Jena 2.10.1 / SDB 1.3.6 --
>> testing for next release
>>
>> We'd like to get testing reports on the current Jena development
>> build over the next few weeks for a release of Jena 2.10.1.
>>
>> You can get a copy of the development build (via maven dependency
>> or a download):
>>
>> http://jena.staging.apache.org/download/index.html#development-builds
>>
>>
>>
>>
>>
There are two areas of special note: Turtle output and query timeouts.
>>
>> == Turtle output
>>
>> The writer for Turtle which has been rewritten. The exact output
>> layout of the Turtle may change.
>>
>> Full details of using the writing subsystem:
>> http://jena.staging.apache.org/documentation/io/rdf-output.html
>>
>> == Query timeouts (including in Fuseki)
>>
>> Timeouts were not firing in the right places so that often the
>> time-to-first-row was remaining and behaving as the
>> time-to-last-row. This is fixed - if you use query timeouts in
>> Fuseki you'll see a difference in behaviour if you had timeouts
>> going off.
>>
>> Also The status code from a timeouts query was incorrectly 408 -
>> it's now 503.
>>
>> == SDB
>>
>> At the same time, we'd like to do a separate, coordinated release
>> of SDB to align the libraries.
>>
>> But we need help from SDB users in order to get proper testing of
>> SDB. Please test 1.3.6-SNAPSHOT
>>
>> (if there aren't enough test reports, we'll have to then see
>> whether a release of SDB is a good idea or not)
>>
>> Andy
>>
>
RE: Jena 2.10.1 / SDB 1.3.6 -- testing for next release
Posted by "Lebling, David (US SSA)" <da...@baesystems.com>.
Andy,
> The ClassNotFound is just some internal reorganisation to improve the modularity of the code base. That's why I'd prefer not to let SDB get too out of sync
> with the main releases.
I can understand that. The exact problem has to do with other third-party code we are using and cannot update to a newer version. In the end there is a tangle of four different versions of xercesImpl that ends up with the wrong one being loaded for SDB (or possibly Jena itself, since the dependency is IIRC in your parent POM).
> Was there a JIRA raised for the "duplicate node" error?
You posted on 4/17 some ruminations on the cause, etc. I did not raise a JIRA, so if you didn't my guess is there isn't one.
> Seeing that error message makes it a bit clearer to me. It's something to do with the bulk loader (NNodeQuads1740763164) and some othe raction has already
> inserted a node. As the possible values for a row in the node table are fixed for a given primary key, I wonder if it's possible to insert but ignore duplicates
> (which won't an a different duplicate).
> And maybe the LOCK TABLE needs to be further out.
> (/me hopes Damian has better insight here)
>
> WARN [tomcat-http--10] (SDBConnection.java:338) - execUpdate:
> SQLException
> ERROR: duplicate key value violates unique constraint "nodes_pkey"
> Detail: Key (hash)=(-8555076428185164481) already exists.
> LOCK TABLE Nodes; INSERT INTO Nodes (hash, lex, lang, datatype, type)
> SELECT NNodeQuads1740763164.n0 , NNodeQuads1740763164.n1 ,
> NNodeQuads1740763164.n2 , NNodeQuads1740763164.n3 ,
> NNodeQuads1740763164.n4 FROM NNodeQuads1740763164 LEFT JOIN Nodes ON
> (NNodeQuads1740763164.n0=Nodes.hash)
> WHERE Nodes.hash IS NULL
>
> Andy
-----Original Message-----
From: Andy Seaborne [mailto:andy@apache.org]
Sent: Friday, April 26, 2013 6:12 AM
To: users@jena.apache.org
Subject: Re: Jena 2.10.1 / SDB 1.3.6 -- testing for next release
On 25/04/13 22:04, Lebling, David (US SSA) wrote:
> Andy,
>
> I'd love to be able to test SDB 1.3.6 but we are not able to update to
> Jena 2.10.1 for reasons too tedious to go into here, and trying to use
> this SDB with an older version of Jena (*cough* 2.7.3 *cough)
Cough and splutter.
> doesn't seem to work, probably not to your surprise. The exact
> exception is: "Caused by: java.lang.ClassNotFoundException:
> org.apache.jena.atlas.lib.Lib". SDB 1.3.5 worked fine in that
> environment, aside from the SDB "duplicate node" error I reported
> earlier.
>
> Dave Lebling
>
> -----Original Message----- From: Andy Seaborne
> [mailto:andy@apache.org] Sent: Thursday, April 25, 2013 3:51 PM To:
> users@jena.apache.org Subject: Jena 2.10.1 / SDB 1.3.6 -- testing for
> next release
>
> We'd like to get testing reports on the current Jena development build
> over the next few weeks for a release of Jena 2.10.1.
>
> You can get a copy of the development build (via maven dependency or a
> download):
>
> http://jena.staging.apache.org/download/index.html#development-builds
>
>
>
> There are two areas of special note: Turtle output and query timeouts.
>
> == Turtle output
>
> The writer for Turtle which has been rewritten. The exact output
> layout of the Turtle may change.
>
> Full details of using the writing subsystem:
> http://jena.staging.apache.org/documentation/io/rdf-output.html
>
> == Query timeouts (including in Fuseki)
>
> Timeouts were not firing in the right places so that often the
> time-to-first-row was remaining and behaving as the time-to-last-row.
> This is fixed - if you use query timeouts in Fuseki you'll see a
> difference in behaviour if you had timeouts going off.
>
> Also The status code from a timeouts query was incorrectly 408 - it's
> now 503.
>
> == SDB
>
> At the same time, we'd like to do a separate, coordinated release of
> SDB to align the libraries.
>
> But we need help from SDB users in order to get proper testing of SDB.
> Please test 1.3.6-SNAPSHOT
>
> (if there aren't enough test reports, we'll have to then see whether a
> release of SDB is a good idea or not)
>
> Andy
>
Re: Jena 2.10.1 / SDB 1.3.6 -- testing for next release
Posted by Andy Seaborne <an...@apache.org>.
On 25/04/13 22:04, Lebling, David (US SSA) wrote:
> Andy,
>
> I'd love to be able to test SDB 1.3.6 but we are not able to update
> to Jena 2.10.1 for reasons too tedious to go into here, and trying to
> use this SDB with an older version of Jena (*cough* 2.7.3 *cough)
Cough and splutter.
> doesn't seem to work, probably not to your surprise. The exact
> exception is: "Caused by: java.lang.ClassNotFoundException:
> org.apache.jena.atlas.lib.Lib". SDB 1.3.5 worked fine in that
> environment, aside from the SDB "duplicate node" error I reported
> earlier.
The ClassNotFound is just some internal reorganisation to improve the
modularity of the code base. That's why I'd prefer not to let SDB get
too out of sync with the main releases.
Was there a JIRA raised for the "duplicate node" error?
Andy
>
> Dave Lebling
>
> -----Original Message----- From: Andy Seaborne
> [mailto:andy@apache.org] Sent: Thursday, April 25, 2013 3:51 PM To:
> users@jena.apache.org Subject: Jena 2.10.1 / SDB 1.3.6 -- testing for
> next release
>
> We'd like to get testing reports on the current Jena development
> build over the next few weeks for a release of Jena 2.10.1.
>
> You can get a copy of the development build (via maven dependency or
> a download):
>
> http://jena.staging.apache.org/download/index.html#development-builds
>
>
>
> There are two areas of special note: Turtle output and query
> timeouts.
>
> == Turtle output
>
> The writer for Turtle which has been rewritten. The exact output
> layout of the Turtle may change.
>
> Full details of using the writing subsystem:
> http://jena.staging.apache.org/documentation/io/rdf-output.html
>
> == Query timeouts (including in Fuseki)
>
> Timeouts were not firing in the right places so that often the
> time-to-first-row was remaining and behaving as the
> time-to-last-row. This is fixed - if you use query timeouts in Fuseki
> you'll see a difference in behaviour if you had timeouts going off.
>
> Also The status code from a timeouts query was incorrectly 408 - it's
> now 503.
>
> == SDB
>
> At the same time, we'd like to do a separate, coordinated release of
> SDB to align the libraries.
>
> But we need help from SDB users in order to get proper testing of
> SDB. Please test 1.3.6-SNAPSHOT
>
> (if there aren't enough test reports, we'll have to then see whether
> a release of SDB is a good idea or not)
>
> Andy
>
RE: Jena 2.10.1 / SDB 1.3.6 -- testing for next release
Posted by "Lebling, David (US SSA)" <da...@baesystems.com>.
Andy,
I'd love to be able to test SDB 1.3.6 but we are not able to update to Jena 2.10.1 for reasons too tedious to go into here, and trying to use this SDB with an older version of Jena (*cough* 2.7.3 *cough) doesn't seem to work, probably not to your surprise. The exact exception is: "Caused by: java.lang.ClassNotFoundException: org.apache.jena.atlas.lib.Lib". SDB 1.3.5 worked fine in that environment, aside from the SDB "duplicate node" error I reported earlier.
Dave Lebling
-----Original Message-----
From: Andy Seaborne [mailto:andy@apache.org]
Sent: Thursday, April 25, 2013 3:51 PM
To: users@jena.apache.org
Subject: Jena 2.10.1 / SDB 1.3.6 -- testing for next release
We'd like to get testing reports on the current Jena development build over the next few weeks for a release of Jena 2.10.1.
You can get a copy of the development build (via maven dependency or a
download):
http://jena.staging.apache.org/download/index.html#development-builds
There are two areas of special note: Turtle output and query timeouts.
== Turtle output
The writer for Turtle which has been rewritten. The exact output layout of the Turtle may change.
Full details of using the writing subsystem:
http://jena.staging.apache.org/documentation/io/rdf-output.html
== Query timeouts (including in Fuseki)
Timeouts were not firing in the right places so that often the time-to-first-row was remaining and behaving as the time-to-last-row.
This is fixed - if you use query timeouts in Fuseki you'll see a difference in behaviour if you had timeouts going off.
Also The status code from a timeouts query was incorrectly 408 - it's now 503.
== SDB
At the same time, we'd like to do a separate, coordinated release of SDB to align the libraries.
But we need help from SDB users in order to get proper testing of SDB.
Please test 1.3.6-SNAPSHOT
(if there aren't enough test reports, we'll have to then see whether a release of SDB is a good idea or not)
Andy