public class TestNamedGraphs extends AbstractDataDrivenSPARQLTestCase
AbstractDataDrivenSPARQLTestCase.TestHelper, AbstractDataDrivenSPARQLTestCase.UpdateTestHelperAbstractDataAndSPARQLTestCase.AbsHelperTestCase2.MyProperties, TestCase2.RandomTypebaseURI, store, valueFactory_randomType| Constructor and Description |
|---|
TestNamedGraphs() |
TestNamedGraphs(String name) |
| Modifier and Type | Method and Description | ||
|---|---|---|---|
void |
test_8_2_1()
8.2.1 Specifying the Default Graph
|
||
void |
test_8_2_3()
8.2.3 Combining FROM and FROM NAMED
|
||
void |
test_8_3_1()
8.3.1 Accessing Graph Names
The following two graphs will be used in examples:
|
||
void |
test_8_3_2()
8.3.2 Restricting by Graph IRI
The following two graphs will be used in examples:
|
||
void |
test_8_3_3()
8.3.3 Restricting Possible Graph IRIs
The following two graphs will be used in examples:
|
||
void |
test_default_graph_joins_01a()
One graph in the defaultGraphs set, but the specified graph has no data.
|
||
void |
test_default_graph_joins_01b()
The data set is not specified.
|
||
void |
test_default_graph_joins_01c()
Two graphs (c1,c2) are used.
|
||
void |
test_default_graph_joins_01d()
Named graph query finds everyone who loves someone and the graph in which
that relationship was asserted.
|
||
void |
test_default_graph_joins_01e()
Named graph query finds everyone who loves someone and the state in which
they live.
|
||
void |
test_default_graph_joins_01f()
Named graph query finds everyone who loves someone and the graph in which
that relationship was asserted, and the state in which they live.
|
||
void |
test_named_graphs_ticket_359()
Unit test for case where there is a single named group which will be
visited by the query.
|
||
void |
test_named_graphs_ticket_888()
Note: This is a duplicate of
voidtest_named_graphs_ticket_888b()
Unit test of a work around for
test_named_graphs_ticket_888(). | ||
void |
test_namedGraphs_01a()
A series of quads mode unit tests for named and default graph query of a
data set containing a single triple.
|
||
void |
test_namedGraphs_01b()
This version of the query specifies a FROM clause and hence causes the
Dataset to become non-null but does not specify any
FROM NAMED clauses. |
||
void |
test_namedGraphs_01c() |
||
void |
test_namedGraphs_01d() |
assertSameAST, asSet, asSet, asSet, asSet, asSet, enableDeleteMarkersInIndes, getBOpContext, getProperties, getStore, makeIV, setUp, tearDownassertSameSolutions, assertSameSolutions, assertSameSolutions, assertSameSolutionsAnyOrder, assertSameSolutionsAnyOrder, assertSameSolutionsAnyOrder, assertSameSolutionsAnyOrder, assertSameSolutionsAnyOrder, assertSameSolutionsAnyOrder, compareGraphs, compareTupleQueryResults, diffassertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEqualsWithinUlps, assertSameArray, assertSameArray, assertSameBigDecimal, assertSameBigDecimal, assertSameBigInteger, assertSameBigInteger, assertSameIterator, assertSameIterator, assertSameIteratorAnyOrder, assertSameIteratorAnyOrder, assertSameValue, assertSameValue, assertZeroUlps, assertZeroUlps, fail, getInnerCause, getNormalInt, getProjectBuildPath, getRandomObject, getRandomObject, getRandomOrder, getRandomString, getTestInputStream, getTestResource, getTestResource, getUlps, getUlps, isDEBUG, isDEBUG, isINFO, isINFO, isInnerCause, logPropertiesassertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertFalse, assertFalse, assertNotNull, assertNotNull, assertNotSame, assertNotSame, assertNull, assertNull, assertSame, assertSame, assertTrue, assertTrue, countTestCases, createResult, fail, fail, failNotEquals, failNotSame, failSame, format, getName, run, run, runBare, runTest, setName, toStringpublic TestNamedGraphs()
public TestNamedGraphs(String name)
public void test_namedGraphs_01a()
throws Exception
Exceptionpublic void test_namedGraphs_01b()
throws Exception
Dataset to become non-null but does not specify any
FROM NAMED clauses. However, this query (like all the others in this
series) is only querying the named graphs.
Note: The correct result for this query should be NO solutions. This is one of the cases covered by the DAWG/TCK graph-02 and graph-04 tests. One of those tests verifies that when the data is from the default graph and the query is against the named graphs then there are no solutions. The other test verifies that the opposite is also true - that when the data are from the named graphs and the query is against the default graph that there are no solutions.
Exceptionpublic void test_8_2_1()
throws Exception
Each FROM clause contains an IRI that indicates a graph to be used to form the default graph. This does not put the graph in as a named graph.
In this example, the RDF Dataset contains a single default graph and no named graphs:
# Default graph (stored at http://example.org/foaf/aliceFoaf)
Exceptionpublic void test_8_2_3()
throws Exception
The FROM clause and FROM NAMED clause can be used in the same query.
# Default graph (stored at http://example.org/dft.ttl)
Exceptionpublic void test_8_3_1()
throws Exception
# Named graph: http://example.org/foaf/aliceFoaf
Exceptionpublic void test_8_3_2()
throws Exception
# Named graph: http://example.org/foaf/aliceFoaf
Exceptionpublic void test_8_3_3()
throws Exception
# Named graph: http://example.org/foaf/aliceFoaf
Exceptionpublic void test_default_graph_joins_01a()
throws Exception
Exceptionpublic void test_default_graph_joins_01b()
throws Exception
Note: In this case there is a duplicate solution based on the duplicate (john,loves,mary) triple which gets filtered out.
Exceptionpublic void test_default_graph_joins_01c()
throws Exception
There is a second solution if c4 is considered, but it should not be since it is not in the default graph.
If you are getting an extra (john,mark,paul) solution then the default graph access path is not enforcing "DISTINCT SPO" semantics.
Exceptionpublic void test_default_graph_joins_01d()
throws Exception
Note: There is an additional occurrence of the relationship in [c4], but the query does not consider that graph and that occurrence should not be matched.
Note: there is a statement duplicated in two of the named graphs (john,loves,mary) so we can verify that both occurrences are reported.
Note: This query DOES NOT USE JOINS. See the next example below for one that does.
Exceptionpublic void test_default_graph_joins_01e()
throws Exception
Exceptionpublic void test_default_graph_joins_01f()
throws Exception
Note: There is an additional occurrence of the relationship in [c4], but the query does not consider that graph and that occurrence should not be matched.
Note: there is a statement duplicated in two of the named graphs (john,loves,mary) so we can verify that both occurrences are reported.
Note: This test case can fail if the logic is leaving [c] unbound when it should be restricting [c] to the specific graphs in the FROM NAMED clauses.
Exceptionpublic void test_named_graphs_ticket_359()
throws Exception
IV for that graph in order to
restrict the query to exactly the desired graph (rather than using an
expander pattern). However, the graph variable also needs to become bound
in the query solutions. If we simply replace the graph variable with a
constant, then the as-bound value of the graph variable will not be
reported in the result set.Exceptionhttps://sourceforge.net/apps/trac/bigdata/ticket/359public void test_named_graphs_ticket_888()
throws Exception
Exceptionpublic void test_named_graphs_ticket_888b()
throws Exception
test_named_graphs_ticket_888().ExceptionCopyright © 2006–2019 SYSTAP, LLC DBA Blazegraph. All rights reserved.