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 #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 #176 (New): A more descriptive exception needed in case of triples modifications to...https://code.mulgara.org/issues/1762009-01-08T00:20:08Zamit -amit@foo.bar
<p>The exception thrown by Mulgara when triple operations are peformed on a non-existent graph is quite confusing. For example, currently you might see:</p>
<pre>
org.mulgara.query.QueryException: Unsupported protocol for destination graph (local, -1 : 'local')
</pre>
<p>It would be a little more useful to see:</p>
<pre>
org.mulgara.query.MissingGraphException: Graph <graph uri> not created in store.
</pre>
<p>or something like that.</p> Mulgara - Feature #172 (New): Add Talis changeset files as an uploadable file type on the SPARQL/...https://code.mulgara.org/issues/1722008-11-21T00:51:00ZPaula Gearon
<p>HTTP updates currently only allow a single TQL command.</p>
<p>SPARQL update will address some of this, but a more flexible approach will be to support Talis changeset files. Note that these files only permit modification on a single subject at a time, though they can include both inserts and deletes in the same file.</p>
<p><a class="external" href="http://vocab.org/changeset/schema">http://vocab.org/changeset/schema</a></p> Mulgara - Feature #168 (New): Add collection support to RLog AND ruleshttps://code.mulgara.org/issues/1682008-11-10T17:37:38ZPaula Gearon
<p>RLog needs a collection syntax, which needs to be converted to the appropriate "walk" constraints in the rules engine.</p>
<p>For instance, see rule S35 in <a href="http://mulgara.org/trac/attachment/wiki/SKOS/skos.rlog" class="external">skos.rlog</a>:</p>
<pre></pre> Mulgara - Feature #116 (New): All answers are DISTINCThttps://code.mulgara.org/issues/1162008-05-17T23:01:21ZPaula Gearon
<p>Answers never have duplicates. SPARQL requires that duplicates remain unless removed with DISTINCT.</p>
<p>This will need changes to the Resolver API, and so are being delayed for a later release.</p> 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>