Mulgara Project: Issueshttps://code.mulgara.org/https://code.mulgara.org/favicon.ico?15861924492012-02-07T21:37:21ZMulgara Project
Redmine Mulgara - Bug #213 (New): Error on ORDER BY variables projected away by SELECT clausehttps://code.mulgara.org/issues/2132012-02-07T21:37:21ZAlex Hall -alexhall@revelytix.com
<p>A SPARQL query that mentions a variable in an ORDER BY expression that appears in the WHERE clause but is projected away by the SELECT clause incorrectly causes an exception to be thrown. According to SPARQL, ordering is applied prior to projection, so this should be valid. This appears to be a case where TQL and SPARQL semantics are mis-aligned.</p> 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 #206 (New): MulgaraUserConfig uses system classloader for conf/mulgara-x-config.xmlhttps://code.mulgara.org/issues/2062009-09-27T18:54:16ZKarsten Huneycutt -kph@skuld.us
<p>The <a class="wiki-page new" href="https://code.mulgara.org/projects/mulgara/wiki/MulgaraUserConfig">MulgaraUserConfig</a> class uses the system class loader to find conf/mulgara-x-config.xml. In some cases, the system class loader is not necessarily the class loader that was used to load the mulgara jar, so it is unable to find the config file that is in the mulgara jar.</p>
<p>The simple fix is to change </p>
<pre><code>URL sysUrl = [[ClassLoader]].getSystemResource(CONFIG_PATH);</code></pre>
<p>to</p>
<pre><code>URL sysUrl = this.getClass().getClassLoader().getResource(CONFIG_PATH);</code></pre>
<p>in src/jar/server/java/org/mulgara/server/MulgaraUserConfig.java, line 89.</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 - Feature #71 (New): Clean up DatabaseOperationContexthttps://code.mulgara.org/issues/712007-09-13T08:57:10ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">This is the next cleanup refactoring.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
We have:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
[[ResolverFactory]] findModelResolverFactory(long model)
<span class="nt"><br/></span>
[[ResolverFactory]] findUncachedExternalResolverFactory(long model)
<span class="nt"><br/></span>
[[ResolverFactory]] findModelTypeResolverFactory(URI modelTypeURI)
<span class="nt"><br/></span>
Resolver obtainResolver(ResolverFactory resolverFactory)
<span class="nt"><br/></span>
URI mapToModelTypeURI(URI modelURL)
<span class="nt"><br/></span>
URI findModelTypeURI(long model)
<span class="nt"><br/></span>
String findProtocol(long n)
<span class="nt"><br/></span>
<span class="nt"><br/></span>
most of which do multiple overlapping tasks, often implemented slightly differently.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Most of these methods used to live in different classes, and have migrated here as their homes were refactored and tidied.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
[[DatabaseOperationContext]] and [[LocalQueryResolver]] are the last two dumping grounds in the system-core where we have left the cruft that was too difficult to clean up concurrently with previous refactorings; and [[DatabaseOperationContext]] is by far the worst of the two - so it's next on the list.
</code></pre> 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 - Bug #52 (New): Insufficient dereferencing in TransactionalAnswer.sessionClose leading t...https://code.mulgara.org/issues/522007-03-19T07:03:14ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">There is a need for the normal error-path to properly dereference and cleanup transactions so that exceptional failures within the error-path can be logged without being lost in 'noise'.
</code></pre> Mulgara - Feature #27 (New): Eliminate all use of static variables from Mulgarahttps://code.mulgara.org/issues/272006-10-16T07:13:57ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">The use of static (ie. global) variables prevents Mulgara being restarted within a jvm. These are not necessary, and are being used to avoid considering where objects belong within the system.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Note this does not apply to static *constants* - being compile-time immutable values they are not an issue.
</code></pre> Mulgara - Feature #23 (New): We must find a more descriptive way of expressing the cost of iterat...https://code.mulgara.org/issues/232006-09-26T11:08:34ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">An increasing number of resolvers (relational, federating, distributed) cannot provide a meaningful upper-bound to their row-count.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Also row-count assumes a uniform cost of iteration, when iteration (as opposed to resolution) entails network latency this is unrealistic.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
How do we handle this? Do we need some sort of bogomips-like timing constant to provide a baseline for comparison? Can we use this to also provide selectivity data that would also improve our join performance?
</code></pre> Mulgara - Feature #22 (New): Make from clause optionalhttps://code.mulgara.org/issues/222006-09-26T04:13:24ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">Consider the following query:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
select $type
<span class="nt"><br/></span>
(select $s from <span class="ni">&lt;</span>server<span class="ni">&gt;</span> where $s <span class="ni">&lt;</span>rdf:type<span class="ni">&gt;</span> $type and $s <span class="ni">&lt;</span>p<span class="ni">&gt;</span> <span class="ni">&lt;</span>o<span class="ni">&gt;</span>)
<span class="nt"><br/></span>
from <span class="ni">&lt;</span>server<span class="ni">&gt;</span>
<span class="nt"><br/></span>
where $type <span class="ni">&lt;</span>mulgara:is<span class="ni">&gt;</span> <span class="ni">&lt;</span>test:Class<span class="ni">&gt;</span> ;
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Mandating from clauses is regularly redundant, and clutters the query.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
While from is the most common example, I have come across examples for every component of a itql query where they are redundant. Apart from mandating the keyword 'select', to identify it as a query, we should probably make the rest of the query should be optional.
<span class="nt"><br/></span>
</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> Mulgara - Bug #8 (New): Temp directory managementhttps://code.mulgara.org/issues/82006-07-11T13:50:53Zbrian -brian@foo.bar
<pre>
<code class="html syntaxhl">A research group has reported seeing Kowari fill up temp directories and fall over. This was on Solaris, but it might be a more general problem to solve. Nothing to reproduce it yet, but I just wanted to capture the experience to potentially investigate this issue moving forward.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
The usage pattern was one big load and then mostly queries with the occasional insert.
</code></pre>