[jira] [Assigned] (JENA-1007) harden query builder tests
[
https://issues.apache.org/jira/browse/JENA-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Warren reassigned JENA-1007:
---
Assignee: Claude Warren
harden query builder tests
---
Key: JENA-1007
URL: https://issues.apache.org/jira/browse/JENA-1007
Project: Apache Jena
Issue Type: Improvement
Components: QueryBuilder
Reporter: Claude Warren
Assignee: Claude Warren
Priority: Minor
The problem is in the way jena-querybuilder does testing. It does a regex on
the rturn from
{{builder.buildString()}] which in term is {{builder.build().toString()}}.
Testing whether a query is the expected one by using string matching is
fragile. Much better
is to call {{Query.equals}} -- write the expected query, parse it to a
{{Query}} object and
call {{Query::equals}}.
The reason jena-querybuilder is now failing tests is JENA-972 which improves
the string appear
of queries.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Jena dependencies on JDK-Internal APIs
On 10/08/15 15:37, Claude Warren wrote: Howdy, Back on June 15 Andy forwarded a note with the above topic laying out how to run JDeps from Java8 to see if we are dependant upon the JDK-Internal APIs (I don't think so). Did anyone actually run the tests? I could not find any discussion of results. Claude Between looking for import sun.* and the fact that we know that Jena is run on non-Oracle JVMs, it does not seem to be too much of an issue for the code base. If you want to run JDpes, then do so. It might be interesting in itself. Andy
Jena dependencies on JDK-Internal APIs
Howdy, Back on June 15 Andy forwarded a note with the above topic laying out how to run JDeps from Java8 to see if we are dependant upon the JDK-Internal APIs (I don't think so). Did anyone actually run the tests? I could not find any discussion of results. Claude -- I like: Like Like - The likeliest place on the web http://like-like.xenei.com LinkedIn: http://www.linkedin.com/in/claudewarren
[jira] [Created] (JENA-1007) harden query builder tests
Claude Warren created JENA-1007:
---
Summary: harden query builder tests
Key: JENA-1007
URL: https://issues.apache.org/jira/browse/JENA-1007
Project: Apache Jena
Issue Type: Improvement
Components: Jena
Reporter: Claude Warren
Priority: Minor
The problem is in the way jena-querybuilder does testing. It does a regex on
the rturn from
{{builder.buildString()}] which in term is {{builder.build().toString()}}.
Testing whether a query is the expected one by using string matching is
fragile. Much better
is to call {{Query.equals}} -- write the expected query, parse it to a
{{Query}} object and
call {{Query::equals}}.
The reason jena-querybuilder is now failing tests is JENA-972 which improves
the string appear
of queries.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Jena dependencies on JDK-Internal APIs
I have read that the new Java 9 spec will remove all unsafe methods and classes. I'll take a run at this later this week when I get some time. I just wanted to know if it was already done or not. Thx. On Mon, Aug 10, 2015 at 4:49 PM, Andy Seaborne a...@apache.org wrote: On 10/08/15 15:37, Claude Warren wrote: Howdy, Back on June 15 Andy forwarded a note with the above topic laying out how to run JDeps from Java8 to see if we are dependant upon the JDK-Internal APIs (I don't think so). Did anyone actually run the tests? I could not find any discussion of results. Claude Between looking for import sun.* and the fact that we know that Jena is run on non-Oracle JVMs, it does not seem to be too much of an issue for the code base. If you want to run JDpes, then do so. It might be interesting in itself. Andy -- I like: Like Like - The likeliest place on the web http://like-like.xenei.com LinkedIn: http://www.linkedin.com/in/claudewarren
[jira] [Closed] (JENA-1007) harden query builder tests
[
https://issues.apache.org/jira/browse/JENA-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Warren closed JENA-1007.
---
Resolution: Duplicate
As noted -- duplicate of JENA-972
harden query builder tests
---
Key: JENA-1007
URL: https://issues.apache.org/jira/browse/JENA-1007
Project: Apache Jena
Issue Type: Improvement
Components: QueryBuilder
Reporter: Claude Warren
Assignee: Claude Warren
Priority: Minor
The problem is in the way jena-querybuilder does testing. It does a regex on
the rturn from
{{builder.buildString()}] which in term is {{builder.build().toString()}}.
Testing whether a query is the expected one by using string matching is
fragile. Much better
is to call {{Query.equals}} -- write the expected query, parse it to a
{{Query}} object and
call {{Query::equals}}.
The reason jena-querybuilder is now failing tests is JENA-972 which improves
the string appear
of queries.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JENA-975) Improve the quality of jena-querybuilder's tests
[
https://issues.apache.org/jira/browse/JENA-975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Warren updated JENA-975:
---
Assignee: Claude Warren
Component/s: (was: Jena)
QueryBuilder
The problem is in the way jena-querybuilder does testing. It does a regex on
the rturn from
builder.buildString()}] which in term is {{builder.build().toString().
Testing whether a query is the expected one by using string matching is
fragile. Much better
is to call Query.equals – write the expected query, parse it to a Query object
and
call Query::equals.
The reason jena-querybuilder is now failing tests is JENA-972 which improves
the string appear
of queries.
Improve the quality of jena-querybuilder's tests
Key: JENA-975
URL: https://issues.apache.org/jira/browse/JENA-975
Project: Apache Jena
Issue Type: Task
Components: QueryBuilder
Affects Versions: Jena 3.0.0
Reporter: A. Soroka
Assignee: Claude Warren
Priority: Minor
Currently, {{jena-querybuilder}} tests whether a query is the expected one by
using string matching. This is fragile and breaks when the string
representation of a {{Query}} changes. It would be much better to use
{{Query::equals}}, by parsing the correct expected query to a {{Query}}
object and comparing it to the constructed sample.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Fwd: Final Deliveries of GSoC Project (JENA-491)
Hi Qihong,
You may have received the reminder email from Google that the final
evaluation of the GSoC project is approaching. The soft deadline is
17 August, with the hard one on 21 August. It means there're only 2
weeks left for your remaining work. The tests of arq need improving,
as Andy points out. You can also deliver the Fuseki part in the other
branch for review in the mean time. Meanwhile, the documentation can
be composed in jena web page (wiki). In order to save time, I suggest
the 3 parts of the work go on simultaneously:
1) jena/arq: in master branch (to be merged first)
2) jena/fuseki: in JENA-491 branch
3) doc: in jena web page (wiki)
Best regards,
Ying Jiang
On Mon, Aug 10, 2015 at 9:58 PM, Andy Seaborne a...@apache.org wrote:
I've managed to integrate the latest updates.
The scripted ones look, at first glance OK, but the data isn't very rich.
Also, please can we have some API tests in TestAPI. These are JUnit tests
in java. These should be have comprehensive coverage.
I also tried out execConstructTriples(), I noticed that the result is from
all graphs. When just triples are asked for, only those in the default
graph should be returned. Template.getTriples calls Quad.asTriple. But it
needs to deal with just the default graph, and c can't rely on
Quad.asTriple.
Andy
On 10/08/15 12:44, Qihong Lin wrote:
Hi,
I've enriched the syntax tests with short form and default graph
cases.
For execution tests, I add the test support in QueryTest for construct
quad with the scripts files and data files in TRIG (see
jena-arq/testing/ARQ/Construct/*.trig). I think construct quad should
be part of the construct of ARQ. So I add the execution tests in
jena-arq/testing/ARQ/Construct/manifest.ttl.
The fuseki part of construct quad has been implemented (not committed
yet). I'll submit the code as soon as the PR 89 [1] being merged.
Anything to be improved for PR 89 from your reviews?
regards,
Qihong
[1] https://github.com/apache/jena/pull/89
On Thu, Aug 6, 2015 at 8:55 PM, Andy Seaborne a...@apache.org wrote:
Hi - looking better - I see the syntax tests I provided.
Does that set of tests cover all cases of the new syntax?
Next, we need execution tests for ARQ.
There will need to be execute tests in jena-arq as well. These can be
Junit tests in java and do not need to be external script files.
This is separate from testing in Fuseki.
Do you have any other constraints on your time over the next 2 weeks?
Andy
On 06/08/15 04:18, Qihong Lin wrote:
Hi,
I've fixed the bugs related to syntax checks. Please see my latest
commits. Here're the output of the syntax files through qparse (you
can also run ExampleConstructQuads.java to get the results). Are
these with the expected behaviors, especially for
syntax-quad-construct-07.arq?
run-construct-quad-test: File: syntax-quad-construct-01.arq
PREFIX : http://example/
CONSTRUCT { GRAPH :g { :s :p :o } } WHERE {} Output of qparse
--file syntax-quad-construct-01.arq PREFIX : http://example/
CONSTRUCT { GRAPH :g { :s :p :o .} } WHERE { } File:
syntax-quad-construct-02.arq PREFIX : http://example/
CONSTRUCT { GRAPH ?g { ?s ?p ?o } } WHERE { ?s ?p ?o } Output of
qparse --file syntax-quad-construct-02.arq PREFIX :
http://example/
CONSTRUCT { GRAPH ?g { ?s ?p ?o .} } WHERE { ?s ?p ?o }
File: syntax-quad-construct-03.arq PREFIX : http://example/
CONSTRUCT { :s :p :o } WHERE {} Output of qparse --file
syntax-quad-construct-03.arq PREFIX : http://example/
CONSTRUCT { :s :p :o . } WHERE { } File:
syntax-quad-construct-04.arq PREFIX : http://example/
CONSTRUCT { GRAPH ?g { :s :p :o } ?s ?p ?o } WHERE { GRAPH ?g { ?s ?p
?o } } Output of qparse --file syntax-quad-construct-04.arq
PREFIX : http://example/
CONSTRUCT { GRAPH ?g { :s :p :o .} ?s ?p ?o . } WHERE { GRAPH ?g { ?s
?p ?o } } File: syntax-quad-construct-05.arq PREFIX :
http://example/
CONSTRUCT { ?s ?p ?o GRAPH ?g { :s :p :o } } WHERE { GRAPH ?g { ?s ?p
?o } } Output of qparse --file syntax-quad-construct-05.arq
PREFIX : http://example/
CONSTRUCT { ?s ?p ?o . GRAPH ?g { :s :p :o .} } WHERE { GRAPH ?g { ?s
?p ?o } } File: syntax-quad-construct-06.arq PREFIX :
http://example/
CONSTRUCT { GRAPH ?g { :s :p :o } ?s ?p ?o . ?s ?p ?o . GRAPH ?g { ?s
?p ?o } ?s ?p ?o . ?s ?p ?o GRAPH ?g { ?s ?p ?o } } WHERE { GRAPH ?g
{ ?s ?p ?o } } Output of qparse --file
syntax-quad-construct-06.arq PREFIX : http://example/
CONSTRUCT { GRAPH ?g { :s :p :o .} ?s ?p ?o . ?s ?p ?o . GRAPH ?g {
?s ?p ?o .} ?s ?p ?o . ?s ?p ?o . GRAPH ?g { ?s ?p ?o .} } WHERE {
GRAPH ?g { ?s ?p ?o } } File:
syntax-quad-construct-07.arq PREFIX : http://example/
CONSTRUCT { GRAPH urn:x-arq:DefaultGraphNode {:s :p :o .} } WHERE
{} Output of qparse --file syntax-quad-construct-07.arq PREFIX
:
[jira] [Commented] (JENA-988) Open TDB store if exists
[
https://issues.apache.org/jira/browse/JENA-988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14679921#comment-14679921
]
ASF subversion and git services commented on JENA-988:
--
Commit 8c315984418b12ffb348ca8bd087922f66d6e386 in jena's branch
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=8c31598 ]
JENA-988 : Test for whether a disk location is in use or not.
Open TDB store if exists
Key: JENA-988
URL: https://issues.apache.org/jira/browse/JENA-988
Project: Apache Jena
Issue Type: New Feature
Components: Core
Reporter: Eugene Tenkaev
Priority: Minor
Fix For: Jena 3.0.1
Need method for opening TDB store if it exists in specified location without
automatic creation of new one.
For example:{code}TDBFactory.openDatasetGraph{code}
Currently we have only one method: {code}TDBFactory.createDatasetGraph{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (JENA-988) Open TDB store if exists
[
https://issues.apache.org/jira/browse/JENA-988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Seaborne resolved JENA-988.
Resolution: Implemented
Assignee: Andy Seaborne
Fix Version/s: Jena 3.0.1
Open TDB store if exists
Key: JENA-988
URL: https://issues.apache.org/jira/browse/JENA-988
Project: Apache Jena
Issue Type: New Feature
Components: Core
Reporter: Eugene Tenkaev
Assignee: Andy Seaborne
Priority: Minor
Fix For: Jena 3.0.1
Need method for opening TDB store if it exists in specified location without
automatic creation of new one.
For example:{code}TDBFactory.openDatasetGraph{code}
Currently we have only one method: {code}TDBFactory.createDatasetGraph{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (JENA-988) Open TDB store if exists
[
https://issues.apache.org/jira/browse/JENA-988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14679903#comment-14679903
]
Andy Seaborne edited comment on JENA-988 at 8/10/15 10:29 AM:
--
Added a function in TDBFactory to test whether using a location already holds a
TDB database. Given this, the suggested functionality can be built.
was (Author: andy.seaborne):
Added a function in TDBFactory to test whether using a location will create a
fresh database. Given this, the suggested functionality can be built.
Open TDB store if exists
Key: JENA-988
URL: https://issues.apache.org/jira/browse/JENA-988
Project: Apache Jena
Issue Type: New Feature
Components: Core
Reporter: Eugene Tenkaev
Priority: Minor
Need method for opening TDB store if it exists in specified location without
automatic creation of new one.
For example:{code}TDBFactory.openDatasetGraph{code}
Currently we have only one method: {code}TDBFactory.createDatasetGraph{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] jena pull request: Richer Javadocs for Iter and ExtendedIterator
Github user asfgit closed the pull request at: https://github.com/apache/jena/pull/90 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (JENA-988) Open TDB store if exists
[
https://issues.apache.org/jira/browse/JENA-988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14679903#comment-14679903
]
Andy Seaborne commented on JENA-988:
Added a function in TDBFactory to test whether using a location will create a
fresh database. Given this, the suggested functionality can be built.
Open TDB store if exists
Key: JENA-988
URL: https://issues.apache.org/jira/browse/JENA-988
Project: Apache Jena
Issue Type: New Feature
Components: Core
Reporter: Eugene Tenkaev
Priority: Minor
Need method for opening TDB store if it exists in specified location without
automatic creation of new one.
For example:{code}TDBFactory.openDatasetGraph{code}
Currently we have only one method: {code}TDBFactory.createDatasetGraph{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (JENA-1000) tdbdump / tdbloader sequence corrupts rdf:type predicates
[
https://issues.apache.org/jira/browse/JENA-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Seaborne closed JENA-1000.
---
Resolution: Cannot Reproduce
Assignee: Andy Seaborne
Fix Version/s: Jena 3.0.1
Report is consistent with broken run of tdbloader. Without further
information, I can't reproduce this otherwise.
tdbdump / tdbloader sequence corrupts rdf:type predicates
-
Key: JENA-1000
URL: https://issues.apache.org/jira/browse/JENA-1000
Project: Apache Jena
Issue Type: Bug
Components: TDB
Affects Versions: Jena 2.12.1, Jena 2.13.0
Environment: Tested with tdbloader and tdbloader2 versions 2.12.1 and
2.13.0 on Windows/Sun Java 1.7.0_60 and CentOS 6.3/OpenJDK 1.8.0_25. tdbdump
was 2.12.1 on CentOS 6.3/OpenJDK 1.8.0_25.
Reporter: Donald Pellegrino
Assignee: Andy Seaborne
Priority: Critical
Fix For: Jena 3.0.1
Steps to reproduce:
1. A TDB database was exported to N-Quads with tdbdump.
2. The dump file was then imported into a new TDB database with tdbloader2.
3. Observe that all rdf:type predicates were replaced with the same randomly
selected predicate.
Work-around:
A work-around was to run a DELETE/INSERT SPARQL command to reassign rdf:type
predicates after the load:
DELETE { ?s custom:200501898-4-1 ?o }
INSERT { ?s rdf:type ?o }
WHERE {
?s custom:200501898-4-1 ?o
}
Testing:
The behavior was consistent across multiple reloads of the same dump file.
tdbloader and tdbloader2 were both used for loads and they were run on both
Windows and Linux with the same results.
Note that this is a Critical issue as it leads to silent corruption of user
data.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (JENA-960) The construction of jena-cmd
[
https://issues.apache.org/jira/browse/JENA-960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Seaborne resolved JENA-960.
Resolution: Done
Fix Version/s: Jena 3.0.0
jena-base now has the command line processing code.
The construction of jena-cmd
Key: JENA-960
URL: https://issues.apache.org/jira/browse/JENA-960
Project: Apache Jena
Issue Type: Epic
Components: Jena
Reporter: A. Soroka
Priority: Minor
Labels: cli, command-line, commandline
Fix For: Jena 3.0.0
The current machinery supporting Jena's CLI tools is too sophisticated to be
replaced entirely by off-the-shelf parts, but it is also scattered across
several modules. That's not necessary and it could be improved by
constructing a centralizing module {{jena-cmd}}. This module would depend on
SDB, TDB, and any other module that exports CLI tools as products.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (JENA-960) The construction of jena-cmd
[
https://issues.apache.org/jira/browse/JENA-960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Seaborne closed JENA-960.
--
The construction of jena-cmd
Key: JENA-960
URL: https://issues.apache.org/jira/browse/JENA-960
Project: Apache Jena
Issue Type: Epic
Components: Jena
Reporter: A. Soroka
Priority: Minor
Labels: cli, command-line, commandline
Fix For: Jena 3.0.0
The current machinery supporting Jena's CLI tools is too sophisticated to be
replaced entirely by off-the-shelf parts, but it is also scattered across
several modules. That's not necessary and it could be improved by
constructing a centralizing module {{jena-cmd}}. This module would depend on
SDB, TDB, and any other module that exports CLI tools as products.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] jena pull request: Richer Javadocs for Iter and ExtendedIterator
Github user ajs6f commented on the pull request: https://github.com/apache/jena/pull/90#issuecomment-129442497 Since commit https://github.com/apache/jena/commit/fd5a94ae61bcd32d2a82cebb6d088d0d81f1da39 contains literally none of the usage advice that was the only purpose of this PR and merely reformats the extant comments, this PR should probably be marked rejected, not closed with. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (JENA-1000) tdbdump / tdbloader sequence corrupts rdf:type predicates
[
https://issues.apache.org/jira/browse/JENA-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14680111#comment-14680111
]
Donald Pellegrino commented on JENA-1000:
-
The broken run of tdbloader makes sense. If I find input for reliable
reproduction I will post that in the future. Note that the TDB database
exhibiting the corruption had been loaded with multiple tdbloader sessions as
well as uploads of files to the Apache Jena Fuseki interface over time. Some of
those operations may have been terminated before completion. Enhancements to
the bulk loaders that prevent database corruption may get at the root cause of
this issue.
tdbdump / tdbloader sequence corrupts rdf:type predicates
-
Key: JENA-1000
URL: https://issues.apache.org/jira/browse/JENA-1000
Project: Apache Jena
Issue Type: Bug
Components: TDB
Affects Versions: Jena 2.12.1, Jena 2.13.0
Environment: Tested with tdbloader and tdbloader2 versions 2.12.1 and
2.13.0 on Windows/Sun Java 1.7.0_60 and CentOS 6.3/OpenJDK 1.8.0_25. tdbdump
was 2.12.1 on CentOS 6.3/OpenJDK 1.8.0_25.
Reporter: Donald Pellegrino
Assignee: Andy Seaborne
Priority: Critical
Fix For: Jena 3.0.1
Steps to reproduce:
1. A TDB database was exported to N-Quads with tdbdump.
2. The dump file was then imported into a new TDB database with tdbloader2.
3. Observe that all rdf:type predicates were replaced with the same randomly
selected predicate.
Work-around:
A work-around was to run a DELETE/INSERT SPARQL command to reassign rdf:type
predicates after the load:
DELETE { ?s custom:200501898-4-1 ?o }
INSERT { ?s rdf:type ?o }
WHERE {
?s custom:200501898-4-1 ?o
}
Testing:
The behavior was consistent across multiple reloads of the same dump file.
tdbloader and tdbloader2 were both used for loads and they were run on both
Windows and Linux with the same results.
Note that this is a Critical issue as it leads to silent corruption of user
data.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JENA-1000) tdbdump / tdbloader sequence corrupts rdf:type predicates
[
https://issues.apache.org/jira/browse/JENA-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14680116#comment-14680116
]
Donald Pellegrino commented on JENA-1000:
-
The custom: prefix was not input during any load or insert operations. The
200501898-4-1 predicate appeared to have changed namespaces on its own.
tdbdump / tdbloader sequence corrupts rdf:type predicates
-
Key: JENA-1000
URL: https://issues.apache.org/jira/browse/JENA-1000
Project: Apache Jena
Issue Type: Bug
Components: TDB
Affects Versions: Jena 2.12.1, Jena 2.13.0
Environment: Tested with tdbloader and tdbloader2 versions 2.12.1 and
2.13.0 on Windows/Sun Java 1.7.0_60 and CentOS 6.3/OpenJDK 1.8.0_25. tdbdump
was 2.12.1 on CentOS 6.3/OpenJDK 1.8.0_25.
Reporter: Donald Pellegrino
Assignee: Andy Seaborne
Priority: Critical
Fix For: Jena 3.0.1
Steps to reproduce:
1. A TDB database was exported to N-Quads with tdbdump.
2. The dump file was then imported into a new TDB database with tdbloader2.
3. Observe that all rdf:type predicates were replaced with the same randomly
selected predicate.
Work-around:
A work-around was to run a DELETE/INSERT SPARQL command to reassign rdf:type
predicates after the load:
DELETE { ?s custom:200501898-4-1 ?o }
INSERT { ?s rdf:type ?o }
WHERE {
?s custom:200501898-4-1 ?o
}
Testing:
The behavior was consistent across multiple reloads of the same dump file.
tdbloader and tdbloader2 were both used for loads and they were run on both
Windows and Linux with the same results.
Note that this is a Critical issue as it leads to silent corruption of user
data.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JENA-960) The construction of jena-cmd
[
https://issues.apache.org/jira/browse/JENA-960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14680120#comment-14680120
]
A. Soroka commented on JENA-960:
In fact, the command line processing code remains scattered across
{{jena-base}} and {{jena-arq}}. For example, command-line-related classes in
{{jena-tdb}} inherit from command line-related classes in {{jena-arq}}. I was
unable to centralize it in {{jena-base}} because much of the code is
undocumented and I do not understand what the workflow or dependencies are. I
would be happy to open a new ticket to document them.
The construction of jena-cmd
Key: JENA-960
URL: https://issues.apache.org/jira/browse/JENA-960
Project: Apache Jena
Issue Type: Epic
Components: Jena
Reporter: A. Soroka
Priority: Minor
Labels: cli, command-line, commandline
Fix For: Jena 3.0.0
The current machinery supporting Jena's CLI tools is too sophisticated to be
replaced entirely by off-the-shelf parts, but it is also scattered across
several modules. That's not necessary and it could be improved by
constructing a centralizing module {{jena-cmd}}. This module would depend on
SDB, TDB, and any other module that exports CLI tools as products.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Fwd: Final Deliveries of GSoC Project (JENA-491)
Hi,
I've enriched the syntax tests with short form and default graph cases.
For execution tests, I add the test support in QueryTest for construct
quad with the scripts files and data files in TRIG (see
jena-arq/testing/ARQ/Construct/*.trig). I think construct quad should
be part of the construct of ARQ. So I add the execution tests in
jena-arq/testing/ARQ/Construct/manifest.ttl.
The fuseki part of construct quad has been implemented (not committed
yet). I'll submit the code as soon as the PR 89 [1] being merged.
Anything to be improved for PR 89 from your reviews?
regards,
Qihong
[1] https://github.com/apache/jena/pull/89
On Thu, Aug 6, 2015 at 8:55 PM, Andy Seaborne a...@apache.org wrote:
Hi - looking better - I see the syntax tests I provided.
Does that set of tests cover all cases of the new syntax?
Next, we need execution tests for ARQ.
There will need to be execute tests in jena-arq as well. These can be
Junit tests in java and do not need to be external script files.
This is separate from testing in Fuseki.
Do you have any other constraints on your time over the next 2 weeks?
Andy
On 06/08/15 04:18, Qihong Lin wrote:
Hi,
I've fixed the bugs related to syntax checks. Please see my latest
commits. Here're the output of the syntax files through qparse (you
can also run ExampleConstructQuads.java to get the results). Are
these with the expected behaviors, especially for
syntax-quad-construct-07.arq?
run-construct-quad-test: File: syntax-quad-construct-01.arq
PREFIX : http://example/
CONSTRUCT { GRAPH :g { :s :p :o } } WHERE {} Output of qparse
--file syntax-quad-construct-01.arq PREFIX : http://example/
CONSTRUCT { GRAPH :g { :s :p :o .} } WHERE { } File:
syntax-quad-construct-02.arq PREFIX : http://example/
CONSTRUCT { GRAPH ?g { ?s ?p ?o } } WHERE { ?s ?p ?o } Output of
qparse --file syntax-quad-construct-02.arq PREFIX :
http://example/
CONSTRUCT { GRAPH ?g { ?s ?p ?o .} } WHERE { ?s ?p ?o }
File: syntax-quad-construct-03.arq PREFIX : http://example/
CONSTRUCT { :s :p :o } WHERE {} Output of qparse --file
syntax-quad-construct-03.arq PREFIX : http://example/
CONSTRUCT { :s :p :o . } WHERE { } File:
syntax-quad-construct-04.arq PREFIX : http://example/
CONSTRUCT { GRAPH ?g { :s :p :o } ?s ?p ?o } WHERE { GRAPH ?g { ?s ?p
?o } } Output of qparse --file syntax-quad-construct-04.arq
PREFIX : http://example/
CONSTRUCT { GRAPH ?g { :s :p :o .} ?s ?p ?o . } WHERE { GRAPH ?g { ?s
?p ?o } } File: syntax-quad-construct-05.arq PREFIX :
http://example/
CONSTRUCT { ?s ?p ?o GRAPH ?g { :s :p :o } } WHERE { GRAPH ?g { ?s ?p
?o } } Output of qparse --file syntax-quad-construct-05.arq
PREFIX : http://example/
CONSTRUCT { ?s ?p ?o . GRAPH ?g { :s :p :o .} } WHERE { GRAPH ?g { ?s
?p ?o } } File: syntax-quad-construct-06.arq PREFIX :
http://example/
CONSTRUCT { GRAPH ?g { :s :p :o } ?s ?p ?o . ?s ?p ?o . GRAPH ?g { ?s
?p ?o } ?s ?p ?o . ?s ?p ?o GRAPH ?g { ?s ?p ?o } } WHERE { GRAPH ?g
{ ?s ?p ?o } } Output of qparse --file
syntax-quad-construct-06.arq PREFIX : http://example/
CONSTRUCT { GRAPH ?g { :s :p :o .} ?s ?p ?o . ?s ?p ?o . GRAPH ?g {
?s ?p ?o .} ?s ?p ?o . ?s ?p ?o . GRAPH ?g { ?s ?p ?o .} } WHERE {
GRAPH ?g { ?s ?p ?o } } File:
syntax-quad-construct-07.arq PREFIX : http://example/
CONSTRUCT { GRAPH urn:x-arq:DefaultGraphNode {:s :p :o .} } WHERE
{} Output of qparse --file syntax-quad-construct-07.arq PREFIX
: http://example/
CONSTRUCT { :s :p :o . } WHERE { } File:
syntax-quad-construct-08.arq PREFIX : http://example/
CONSTRUCT { GRAPH ?g { :s :p :o } GRAPH ?g1 { :s :p :o } } WHERE { }
Output of qparse --file syntax-quad-construct-08.arq PREFIX :
http://example/
CONSTRUCT { GRAPH ?g { :s :p :o .} GRAPH ?g1 { :s :p :o .} } WHERE {
}
On Sun, Aug 2, 2015 at 9:14 AM, Ying Jiang jpz6311...@gmail.com
wrote:
Hi Qihong,
I re-checked the code you commited. Most of the hashCode issues
for arq.qparse that Andy pointed out are due to the incorrect
serialization of the Template. The code can only deal with the
quads with the same graph node, for which it may not always be the
case in practcial terms. Please make sure each example syntax file
can pass the checking process of arq.qparse.
It's August now. You'd better hurry up and make the project
completed on time in the remaining weeks.
Best regards, Ying Jiang
On Thu, Jul 30, 2015 at 6:03 AM, Andy Seaborne a...@apache.org
wrote:
Output of * each examnple syntax file (the queries are nonsense
in practcial terms!) * running arq.qparse on the file * notes on
what seems to be going on
Andy
File: syntax-quad-construct-01.arq PREFIX :
http://example/
CONSTRUCT { GRAPH :g { :s :p :o } } WHERE {} Output of
qparse --file syntax-quad-construct-01.arq PREFIX :
http://example/
