Mulgara Project: Issueshttps://code.mulgara.org/https://code.mulgara.org/favicon.ico?15861924492009-02-03T05:55:09ZMulgara Project
Redmine Mulgara - Bug #180 (Closed): CONSTRUCT queries only handle 3 columnshttps://code.mulgara.org/issues/1802009-02-03T05:55:09ZPaula Gearon
<p>CONSTRUCT may work with any multiple of 3 elements, however Mulgara only handles a single set of 3.</p>
<p>e.g. The following query:<br /><pre>
construct { $s a ns:item; dc:text $o } where { $s ns:pred $o }
</pre><br />Gives an error of:<br /><pre>
cannot construct graph with 6 columns.
</pre></p> Mulgara - Bug #179 (Closed): Doing a FILTER REGEX with 2 parameters gives an errorhttps://code.mulgara.org/issues/1792009-02-03T05:44:42ZPaula Gearon
<p>Simple queries with 2 parameter regex filters fail with NPE. e.g.:<br /><pre>
select * where { ?s ?p ?o filter regex(?o, ".*sold.*") }
</pre></p>
<pre></pre> Mulgara - Feature #173 (Closed): Implement Accept headershttps://code.mulgara.org/issues/1732008-11-22T15:03:51ZPaula Gearon
<p>The web api current takes "out" as a parameter to define the return type. This should be implemented as a content type defined in the Accept header from the client. See:<br /> <a class="external" href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1">http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1</a></p>
<p>For ease of access with clients that set their own Accept types, the "out" parameter should continue to be accepted, but the name should change to something more sensible, like "type".</p> Mulgara - Bug #169 (Closed): CREATE on the SPARQL protocol should return RDF/XMLhttps://code.mulgara.org/issues/1692008-11-10T21:21:04ZPaula Gearon
<p>CREATE is basically being implemented as a select for 3 columns. That provides the correct data, but in the wrong format.</p>
<p>We need to use the RDF/XML exporter to convert the data being created into an RDF/XML graph.</p> Mulgara - Feature #167 (Closed): Port RLog grammar to JavaCChttps://code.mulgara.org/issues/1672008-11-05T05:19:39ZPaula Gearon
<p>RLog was built in Beaver, as this was a learning exercise for a LALR parser. However, <a class="wiki-page new" href="https://code.mulgara.org/projects/mulgara/wiki/JavaCC">JavaCC</a> (an LL parser) is adequate to the task, and is already integrated for SPARQL.</p> Mulgara - Bug #157 (Closed): WebUI shouldn't need ; on TQLhttps://code.mulgara.org/issues/1572008-10-17T23:05:00ZPaula Gearon
<p>In the <a class="wiki-page" href="https://code.mulgara.org/projects/mulgara/wiki/WebUI">WebUI</a> every TQL command requires a ; character finishing it (or possibly a newline - I need to check). Also, newlines are not treated as whitespace.</p>
Before handing a query off to TQL we should check for the following:
<ul>
<li>If the text does not end in a ; then text to the end should be considered a query on its own.</li>
<li>newline characters should be replaced with spaces.</li>
</ul> Mulgara - Bug #156 (Closed): Translate rmi:// URIs into local URIshttps://code.mulgara.org/issues/1562008-10-17T22:27:27ZPaula Gearon
<p>URIs like:<br /> rmi://host/server#xxx<br />need to be sent to the server, and then have the relative "xxx" turned into the URI that gets used at the server end. Alternatively, the RMI server code should look for a "graph" parameter (ie. rmi://host/server?graph=foo:bar) that will be interpreted at the server end as an absolute URI.</p>
<p>This is dependent on <a class="issue tracker-3 status-27 priority-21 priority-default closed" title="Bug: Allow relative URIs in queries (Closed)" href="https://code.mulgara.org/issues/155">#155</a> due to the need to have both relative and absolute URIs.</p> Mulgara - Bug #155 (Closed): Allow relative URIs in querieshttps://code.mulgara.org/issues/1552008-10-17T22:21:50ZPaula Gearon
<p>Queries current check URIs to see if they are relative or absolute. This is down in the URIReference code, and should be avoided.</p> Mulgara - Bug #152 (Closed): Exception on not-well-formed OPTIONAL querieshttps://code.mulgara.org/issues/1522008-10-15T21:15:54ZPaula Gearon
<p>The W3C test include the following:</p>
<pre><code>Nested-optionals with a shared variable that does not appear in<br /> the middle pattern (a not well-formed query pattern as per<br /> "Semantics and Complexity" of SPARQL</code></pre>
<p>The query is:<br /><pre>
PREFIX : <http://example/>
SELECT *
{
?X :name "paul"
{?Y :name "george" . OPTIONAL { ?X :email ?Z } }
}
</pre><br />There data is on the <a href="http://www.w3.org/2001/sw/DataAccess/tests/r2var-scope-join-1.ttl" class="external">W3C site</a></p>
<p>On running this query we get:<br /><pre>
org.mulgara.query.QueryException: Query failed
at org.mulgara.resolver.DatabaseSession.execute(DatabaseSession.java:754)
at org.mulgara.resolver.DatabaseSession.query(DatabaseSession.java:464)
at org.openrdf.sail.mulgara.MulgaraTripleSource.evaluate(MulgaraTripleSource.java:111)
at org.openrdf.sail.mulgara.MulgaraEvaluationStrategy.evaluate(MulgaraEvaluationStrategy.java:50)
... 27 more
Caused by: org.mulgara.query.MulgaraTransactionException: Transaction rollback triggered
at org.mulgara.resolver.MulgaraInternalTransaction.implicitRollback(MulgaraInternalTransaction.java:516)
at org.mulgara.resolver.MulgaraInternalTransaction.execute(MulgaraInternalTransaction.java:627)
at org.mulgara.resolver.DatabaseSession.execute(DatabaseSession.java:751)
... 30 more
Caused by: org.mulgara.query.QueryException: Failed to resolve constraintExpression
at org.mulgara.resolver.ConstraintOperations.resolveConstraintExpression(ConstraintOperations.java:197)
at org.mulgara.resolver.LocalQueryResolver.resolveE(LocalQueryResolver.java:269)
at org.mulgara.resolver.DatabaseOperationContext.doQuery(DatabaseOperationContext.java:786)
at org.mulgara.resolver.QueryOperation.execute(QueryOperation.java:139)
at org.mulgara.resolver.MulgaraInternalTransaction.execute(MulgaraInternalTransaction.java:623)
... 31 more
Caused by: org.mulgara.query.TuplesException: Bad [[LocalNode]] in constraint. constraint.getElement(0) returned a [[LocalNode]] with value: 0 constraint=[gn0 gn1449 gn1481 gn1369]
at org.mulgara.resolver.store.StatementStoreResolution.defineIndex(StatementStoreResolution.java:308)
at org.mulgara.resolver.store.StatementStoreResolution.<init>(StatementStoreResolution.java:156)
at org.mulgara.resolver.store.StatementStoreResolution.reresolve(StatementStoreResolution.java:371)
at org.mulgara.store.tuples.TuplesOperations.resolveNewlyBoundFreeNames(TuplesOperations.java:563)
at org.mulgara.store.tuples.TuplesOperations.unifyOperands(TuplesOperations.java:464)
at org.mulgara.store.tuples.TuplesOperations.join(TuplesOperations.java:244)
at org.mulgara.resolver.DefaultConstraintHandlers$5.resolve(DefaultConstraintHandlers.java:165)
at org.mulgara.resolver.ConstraintOperations.resolveConstraintExpression(ConstraintOperations.java:187)
... 35 more
</pre></p> Mulgara - Feature #151 (Closed): Emulate graph indexes in XA 1.1https://code.mulgara.org/issues/1512008-10-15T00:05:37ZPaula Gearon
<p>XA 1 had the following indexes:<br /><pre>
GSPO
GPOS
GOSP
SPOG
POSG
OSPG
</pre></p>
<p>XA 1.1 is able to remove the last 3 indexes for most queries, but there are still some queries that require them. In these cases the effect of these indexes can be emulated by using the contents of the system graph. This requires the system resolver to correctly bootstrap itself, as it will need to interrogate itself for information that must be present before the emulation can occur.</p> Mulgara - Bug #150 (Closed): OPTIONAL not returning expected resultshttps://code.mulgara.org/issues/1502008-10-14T23:57:27ZPaula Gearon
<p>Unexpected results on an OPTIONAL clause. The toString on a query that demonstrates the problem is:<br /><pre>
SELECT $o1 $o2
FROM http://mulgara.org/local/server1#
WHERE ( optional ( optional ( and
[$s urn:test:pred1 $o1 $-anon-ctx1]
[$-anon-ctx1 rdf:type http://mulgara.org/mulgara#sailModel
http://mulgara.org/mulgara#sailModel]
) ( and
[$s urn:test:pred2 $o2 $-anon-ctx4]
[$-anon-ctx4 rdf:type http://mulgara.org/mulgara#sailModel
http://mulgara.org/mulgara#sailModel]
)
) ( and
[$s urn:test:pred2 $o2 $-anon-ctx7]
[$-anon-ctx7 rdf:type http://mulgara.org/mulgara#sailModel
http://mulgara.org/mulgara#sailModel]
[$s urn:test:pred3 $o1 $-anon-ctx10]
[$-anon-ctx10 rdf:type http://mulgara.org/mulgara#sailModel
http://mulgara.org/mulgara#sailModel]
)
) GIVEN 0 columns: (1 rows
)
</pre></p>
<p>The data is generated with:<br /><pre>
con.add(subj1, pred1, obj1);
con.add(subj1, pred2, obj2);
con.add(subj1, pred3, obj3);
</pre><br />The results we get are:<br /><pre>
var: $o2
tuples:
{$o2 $-anon-ctx10 $o1 $s $-anon-ctx7 (1 rows)
[000037 000032 000039 000033 000032 ]
}
</pre></p> Mulgara - Feature #149 (Closed): Update WebUI to handle SPARQL querieshttps://code.mulgara.org/issues/1492008-10-08T22:43:06ZPaula Gearon
<p>SPARQL support on the <a class="wiki-page" href="https://code.mulgara.org/projects/mulgara/wiki/WebUI">WebUI</a> is a very common request. We should keep TQL, while adding SPARQL.</p>
<p>Add a function to detect TQL vs SPARQL queries, and create the appropriate interpreter to deal with it.</p> Mulgara - Feature #148 (Closed): Remove Jena dependency in date typeshttps://code.mulgara.org/issues/1482008-09-19T21:03:12ZPaula Gearon
<p>The date types of gYear, gMonth, gDay, gMonthDay and gYearMonth are using Jena XSD classes to wrap the fields in a java.util.Calendar object, despite parsing everything themselves. The work is redundant, and it is creating an artificial dependence on Jena code. This should be removed.</p> Mulgara - Feature #146 (Closed): Factor out HTTP server from EmbeddedMulgaraServerhttps://code.mulgara.org/issues/1462008-09-04T03:56:11ZPaula Gearon
<p>Extract the creation of Server and any web services into a separate class.</p>
<p>Since this class does not need to feed anything back to the main framework, it can be started with reflection easily. This means we can avoid class loading entirely if the setup is not creating web services. This will allow us to avoid a number of jars for many distributions.</p> Mulgara - Feature #145 (Closed): Remove WebUIhttps://code.mulgara.org/issues/1452008-08-30T06:02:09ZPaula Gearon
<p>Remove the <a class="wiki-page" href="https://code.mulgara.org/projects/mulgara/wiki/WebUI">WebUI</a> webapp. Importantly, this also requires the removal of the barracuda jars, and xmlc-*.jar.</p>