Mulgara Project: Issueshttps://code.mulgara.org/https://code.mulgara.org/favicon.ico?15861924492010-01-05T06:40:52ZMulgara Project
Redmine Mulgara - Bug #210 (New): org.mulgara.sparql.parser.cst.AndExpression contains wrong assertionhttps://code.mulgara.org/issues/2102010-01-05T06:40:52Zmartin.gerlach -martin.gerlach@foo.bar
<pre>
<pre>
<pre></pre> Mulgara - Bug #208 (New): Subqueries not supported via RESThttps://code.mulgara.org/issues/2082009-10-20T08:30:52ZEric Kobrin -ekobrin-mulgara@velocitude.com
<p>When making a TQL REST request containing subqueries, <code>StreamedSparqlJSONAnswer</code> throws an exception due to addBinding() not supporting @TransactionalAnswer@s.</p> Mulgara - Bug #207 (New): org.mulgara.protocol.StreamedSparqlJSONObject.emit() produces improper ...https://code.mulgara.org/issues/2072009-10-14T07:18:30ZEric Kobrin -ekobrin-mulgara@velocitude.com
<p>[<a class="source" href="https://code.mulgara.org/projects/mulgara/repository/3/revisions/1379/entry/trunk/src/jar/querylang/java/org/mulgara/protocol/StreamedSparqlJSONObject.java#L56">source:trunk/src/jar/querylang/java/org/mulgara/protocol/StreamedSparqlJSONObject.java@1379#L56</a> <a class="wiki-page new" href="https://code.mulgara.org/projects/mulgara/wiki/StreamedSparqlJSONObject">StreamedSparqlJSONObject</a>.emit()] does not produce proper JSON. The value for the "data" key is not quoted.</p>
<p>This causes TQL "create" and "drop" queries to return a string which will not parse as JSON.</p> Mulgara - Bug #204 (New): TQL Causing Mulgara to hang (regression from 2.0.9 to 2.1.3)https://code.mulgara.org/issues/2042009-09-16T23:13:52ZDragisa Krsmanovic -dkrsmanovic@plos.org
<p>This particular query <em>never</em> returns in Mulgara 2.1.3</p>
<p>In Mulgara 2.0.9 it, correctly, returns with no results under one minute.</p>
<p>Same database was used for testing.</p>
<pre>
select $art $oqltmp1_1 $score0 from <local:///topazproject#prefix>
where $art <rdf:type> <http://rdf.topazproject.org/RDF/Article> in <local:///topazproject#filter:graph=ri>
and $art <http://purl.org/dc/terms/bibliographicCitation> $oqltmp2_2 in <local:///topazproject#filter:graph=ri>
and $oqltmp2_2 <http://rdf.plos.org/RDF/hasEditorList> $oqltmp2_3 in <local:///topazproject#filter:graph=ri>
and $oqltmp2_4 <mulgara:prefix> <rdf:_> in <local:///topazproject#prefix>
and $oqltmp2_3 $oqltmp2_4 $oqltmp2_1 in <local:///topazproject#filter:graph=ri>
and $oqltmp2_1 <mulgara:search> $oqltmp2_7fs in <local:///topazproject#lucene>
and $oqltmp2_7fs <http://xmlns.com/foaf/0.1/name> '"niyaz ahmed"' in <local:///topazproject#lucene>
and $oqltmp2_7fs <mulgara:score> $score0 in <local:///topazproject#lucene>
and $art <http://prismstandard.org/namespaces/1.2/basic/eIssn> $oqltmp1_1 in <local:///topazproject#filter:graph=ri>;
</pre> Mulgara - Bug #203 (New): Mulgara RMI Connection Issuehttps://code.mulgara.org/issues/2032009-09-14T18:23:55ZJoe Osowski -josowski@plos.org
<p>I'm seeing some strange behavior here when connecting to a remote mulgara server. It looks like we've got something misconfigured, but I haven't been able to nail it down yet.</p>
<p>The ambra and mulgara instances that are installed on the same server and can talk to eachother fine. But when I try to connect to this instance of mulgara from my development workstation, it just times out. I turned up the debug logging for mulgara and this is what I see:</p>
<p>2009-09-03 09:35:43,731 ERROR <a class="wiki-page new" href="https://code.mulgara.org/projects/mulgara/wiki/MulgaraXAResourceContext">MulgaraXAResourceContext</a>> Failed to create transaction [RMI TCP Connection(22)-10.135.2.71 org.mulgara.resolver.MulgaraXAResourceContext]<br /> org.mulgara.query.MulgaraTransactionException: Interrupted while waiting for write lock<br /> at org.mulgara.resolver.MulgaraTransactionManager.obtainWriteLock(MulgaraTransactionManager.java:97)<br /> at org.mulgara.resolver.MulgaraExternalTransactionFactory.createTransaction(MulgaraExternalTransactionFactory.java:93)<br /> at org.mulgara.resolver.MulgaraXAResourceContext$MulgaraXAResource.start(MulgaraXAResourceContext.java:371)<br /> at org.mulgara.server.rmi.XAResourceWrapperRemoteXAResource.start(XAResourceWrapperRemoteXAResource.java:100)</p>
<p>I believe the interrupted exception is caused by the fact that I stopped my local ambra instance and the connection was closed. It appears to be waiting for a write lock for some reason.</p>
<p>Strangely, when I start Mulgara with the webserver, RMI starts working as well. Turn off the web server, and I'm back to the same problem.</p>
<p>Here are the parameters that I am passing Mulgara that enables RMI to work:</p>
<p>-r 8111 -t 8111 -p 8001 -u 8011 -o plosone-branch.plos.org -k plosone-branch.plos.org</p>
<p>Here are the params that we had before:</p>
<p>-r 8111 -t 8111 --nohttp</p> Mulgara - Bug #202 (New): SPARQL queries with non-ascii chars failhttps://code.mulgara.org/issues/2022009-09-06T14:49:10ZGregg -gar@foo.bar
<p>I'm able to successfully load UTF-8 data with non-ascii characters, both in URIs and in literals (Mulgara 2.1.3). SPARQL queries against the data succeed so long as such non-ascii values match variables. However, if the query itself contains non-ascii chars it fails.</p>
<p>For example, if my data includes something like<br /><pre>
eg:Foo a eg:Füß
</pre><br />then a query like<br /><pre>
SELECT ?z WHERE { <eg:Foo> a ?z .}
</pre><br />will succeed, but one like<br /><pre>
SELECT ?x WHERE { ?x a <eg:füß> . }
</pre></p>
<p>will fail.</p>
<p>This is a show-stopper for me, since I need non-ascii Unicode in both my data and my queries.</p> Mulgara - Bug #201 (New): Accept-Charset HTTP header not honoredhttps://code.mulgara.org/issues/2012009-09-06T14:39:02ZGregg -gar@foo.bar
<p>(This ticket obsoletes <a class="issue tracker-3 status-3 priority-33 priority-high2" title="Bug: SPARQL results char encoding (New)" href="https://code.mulgara.org/issues/197">#197</a>)</p>
<p>Currently there doesn't seem to be a way to request a specific character encoding for query results. I think the way to do this is via content negotiation; at least I haven't seen any way to make such a request in SPARQL, but I might be wrong about that. In any case, I need a way to definitely indicate that I want utf-8 for the results.</p>
<p>The Mulgara HTTP interfaces (version 2.1.3) don't seem to honor the Accept-Charset header. Ideally it should be possible to use the header to stipulate any encoding for XML results. For JSON results, it should be possible to stipulate any UTF (utf-8, utf-16, utf-32) or UCS (UCS-4; I understand UCS-2 is obsolete.)</p> Mulgara - Bug #197 (New): SPARQL results char encodinghttps://code.mulgara.org/issues/1972009-09-01T19:59:32ZGregg -gar@foo.bar
<p>The SPARQL Protocol definition says that for the HTTP binding "the whttp:outputSerialization is application/sparql-results+xml with UTF-8 encoding, application/rdf+xml with<br />UTF-8 encoding." (<a href="http://www.w3.org/TR/rdf-sparql-protocol/#query-bindings-http" class="external">Section 2.2</a>) That's for XML results; I haven't found the equivalent requirement for JSON output, but for my application in any case full utf-8 support for json and xml is essential.</p>
<p>As a general matter (principle of least surprise), I think the expected behavior would be "encoding-in equals encoding-out", so if I populate a graph with utf-8 data, query results should be utf-8, no matter the output serialization. Alternatively, one could argue that the standard HTTP 1.1 Accept-Charset header should govern; since it is an HTTP binding, HTTP rules should apply.</p>
<p>The SPARQL Protocol definition doesn't explicitly address character encoding for the SOAP binding, but since SOAP is an HTTP protocol it should probably do utf-8 or honor the Accept-Charset header.</p> Mulgara - Bug #181 (New): Need Authorization for HTTPhttps://code.mulgara.org/issues/1812009-02-04T05:32:53ZPaula Gearon
<p>Now that Mulgara can be put on the web, the write operations need to be locked down, else it cannot be deployed. For HTTP we will need to employ authorization through standard means.</p>
<p>Several questions come out of this. First, how should authorization be handled? In the database? In an external file? Second, should it be done on an operation basis (GET is safe, but PUT/POST is not) or on a graph-by-graph basis like Mulgara security used to employ?</p> Mulgara - Feature #175 (New): Resolver interface needs to provide back-up/restore capabilityhttps://code.mulgara.org/issues/1752008-12-04T22:25:53Zamit -amit@foo.bar
<p>To provide a simple administrative routine, it would help if the resolver interface supported backup and restore capabilities.</p>
<p>This will allow resolvers to also dump their data into a backup, and have restore data brought back in. This will only be applicable to writable resolvers.</p>
<p>Resolvers may also need to mark a new section of the backup file, which will be ignored by other resolvers. This will result in new code that asks each resolver if it <em>can</em> do backups, and during restore it will need to iterate over each resolver to find out with one can handle the data about to be restored (according to a section marker in the backup file)</p> Mulgara - Bug #136 (New): IntervalConstraintDescriptor converts all bounds to xsd:doublehttps://code.mulgara.org/issues/1362008-08-04T20:04:13ZAlex Hall -alexhall@revelytix.com
<p>The <code>Bounds</code> object used by <code>IntervalConstraintDescriptor</code> to store the upper and lower bounds of a constraint stores the bounds as doubles. The <code>IntervalConstraintDescriptor.resolve(...)</code> method always uses <code>SPDouble</code> objects constructed from these bounds when slicing the stringpool. This makes it impossible to compare on datatypes derived from <code>xsd:decimal</code> (i.e. <code>xsd:int</code>, <code>xsd:long</code>, etc).</p>
<p>For instance, the following sequence of TQL commands produces no results:</p>
<pre>
create <rmi://localhost/server1#test>;
insert <test:foo> <rdf:value> '1'^^<http://www.w3.org/2001/XMLSchema#int>
into <rmi://localhost/server1#test>;
select $x from <rmi://localhost/server1#test> where
$x <mulgara:gt> '0'^^<http://www.w3.org/2001/XMLSchema#int> in <sys:xsd>;
</pre> Mulgara - Bug #81 (In Progress): Blank Node Assignment in Inserts inconsistent with autocommithttps://code.mulgara.org/issues/812008-02-28T06:23:04ZAndrae Muys -andrae@netymon.com
<p>It appears that the binding of variables to blank nodes when inserting <br />statements behaves differently depending on whether autocommit is turned <br />on for the session. If I have autocommit turned on and execute the <br />following iTQL commands:<br /><pre>
create <rmi://localhost/server1#test>;
insert <test:subj> <test:pred> $x $x <test:value> 'o1'
into <rmi://localhost/server1#test> ;
insert <test:subj> <test:pred> $x $x <test:value> 'o2'
into <rmi://localhost/server1#test> ;
select $s $p $o from <rmi://localhost/server1#test> where $s $p $o;
</pre><br />Then I see that the variable "x" is bound to different blank nodes in <br />each of the two insertions, and the resulting model has 4 statements. <br />This is the behavior (behaviour?) that I would expect.</p>
<p>However, when I turn autocommit off prior to the first insertion, and <br />turn it back on after the second insertion, then I see that the variable <br />"x" is bound to the <strong>same</strong> blank node in each of the insertions, <br />resulting in 3 total statements in the model, which came as a bit of a <br />surprise to me. Is this the expected behavior in that situation?</p> Mulgara - Feature #57 (New): Extend use of Annotations to improve transparency of deferral based ...https://code.mulgara.org/issues/572007-04-17T05:51:27ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">[[ReresolvableResolution]] needs to be removed and replaced with an Annotation.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
All Major Tuples that provide operations on Tuples need to be modified to provide aggregated access to their operands annotations when their operands provide them.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
As a longer term goal we should rephrase the annotations in terms of complexity estimates for reordering/sorting/etc operations as well as constraints on join ordering to permit more nuanced optimisation of joins - this however needs to wait until we are fully exploiting the capabilities of the existing annotations.
</code></pre> Mulgara - Feature #21 (New): HybridTuples should defer sort and support prefix-define/reresolvehttps://code.mulgara.org/issues/212006-09-26T03:51:34ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">Currently [[HybridTuples]] performs it's sort when it is constructed. This forces the evaluation of its argument before join-optimisation has an opportunity to specify a desired prefix or reresolve. [[HybridTuples]] should defer it's sort until at least the first call to beforeFirst.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Considerations:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Reresolve - If [[HybridTuples]] argument is Reresolvable [[HybridTuples]] should support passing this argument through.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
[[DefinablePrefix]] - If our argument is unordered then a projection is free, so we should expose this to the join optimisation. However note that if we are only sorting once, then we cannot pass this call through to the argument. Rather we should project the argument to maximise the prefix length available.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Single vs. Multiple sorts - A sort is O(nlogn), and a n from m prefix is O((0 from m)^((n - m) / m)). If we can increase the prefix length sufficiently to pay for the cost of the extra sorts we should resort on each call to beforeFirst(). Note that if the argument is itself prefix-definable then the cost of a sort is in terms of the estimated reduced length.
</code></pre> Mulgara - Feature #18 (New): Provide a language independent interface to Mulgara compatible with ...https://code.mulgara.org/issues/182006-09-14T04:38:41ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">We need to support access to the entire Session API from languages other than java.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Both xml-rpc and REST have been proposed as alternatives. OTOH we should probably support both.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
XMLRPC because of it's wide language support and classic-rpc model.
<span class="nt"><br/></span>
REST because it is a better fit to W3C architecture, and provides benefits when working with loosely coupled distribution.
</code></pre>