Mulgara Project: Issueshttps://code.mulgara.org/https://code.mulgara.org/favicon.ico?15861924492009-02-17T08:30:38ZMulgara Project
Redmine Mulgara - Bug #183 (In Progress): project() isn't considered with index selection.https://code.mulgara.org/issues/1832009-02-17T08:30:38ZAndrae Muys -andrae@netymon.com
<p>select $p from <graph:data> where $s $p $o; uses the GSPO index which requires a full external sort of the store to extract $p. If we use GPOS we get $p without the sort.</p>
<p>The problem is that project() call doesn't participate in index ordering within the query optimisation.</p>
<p>The solution is to introduce an Annotation that allows the project to specify a preferred order. Initially supporting this Annotation with <a class="wiki-page new" href="https://code.mulgara.org/projects/mulgara/wiki/StatementStoreResolution">StatementStoreResolution</a> will be sufficient to satisfy the query above. A general solution will also require supporting it with Join and Append tuples.</p> Mulgara - Bug #101 (Closed): Explicit rollback throws exception if called after implicit rollback.https://code.mulgara.org/issues/1012008-04-18T14:30:29ZAndrae Muys -andrae@netymon.com
<pre>
setAutoCommit(false)
query(corrupt-query); - triggers rollback.
rollback();
</pre><br />throws exception (attempt to reserveWriteLock without write-lock).
<p>should be a nop.</p> Mulgara - Feature #91 (In Progress): Refactor OperationContext to provide access to the Operation...https://code.mulgara.org/issues/912008-03-26T03:45:52ZAndrae Muys -andrae@netymon.com
<p>Currently we have multiple Operation classes performing their own explicit insertion routines. This duplication should be refactored into <a class="wiki-page new" href="https://code.mulgara.org/projects/mulgara/wiki/ModifyModelOperation">ModifyModelOperation</a>, and all other operations that require insertion functionality should do so via calls to Session::insert() and Session::delete().</p> Mulgara - Feature #86 (In Progress): Clean up XSD Resolver so it becomes suitable demo-resolverhttps://code.mulgara.org/issues/862008-03-17T01:36:49ZAndrae Muys -andrae@netymon.com
<p>The XSD-Resolver is currently in a very poor state of repair. The Resolver Interface also desperately requires detailed documentation, and this really requires an exemplar resolver.</p>
<p>Clean up the XSD-Resolver so that it can be used as an example of how to write a resolver.</p> Mulgara - Bug #85 (Closed): Merge JTA Branch into trunkhttps://code.mulgara.org/issues/852008-03-08T02:16:01ZAndrae Muys -andrae@netymon.com
<p>Merge JTA Branch into trunk</p> Mulgara - Feature #73 (Closed): Provide access to Mulgara's transaction api via a JTA XAResource ...https://code.mulgara.org/issues/732007-10-16T04:33:26ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">Provide a JTA XAResource that provides access to Mulgara transactions - this will permit Mulgara to participate in externally mediated distributed transactions. So this would permit mulgara transactions to be synchronised with mysql/postgres/J2EE transactions.
</code></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 #69 (Closed): Refactor LocalQuery to clean up call pathshttps://code.mulgara.org/issues/692007-09-10T06:07:19ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">Rationalise the multiple calls to resolve(); rename class [[QueryEvalContext]] or similar and likewise rename [[LocalQueryResolver]] to match. Clean-up to make class more stateless, and consequently to eliminate some of the encapsulation hacks in LQR.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
This will make the model-name fix much cleaner - as well as making it possible to improve the Resolver and Custom-Constraint SPI's.
</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 - Bug #46 (Closed): Track down and resolve Lost-Phase Tokenshttps://code.mulgara.org/issues/462007-02-26T03:52:55ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">Lost-phase tokens lead to resource leaks - as an ongoing concern we need to track down and resolve any lost-phase tokens noticed in the course of normal execution.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Lost-phase tokens are the result of Tuples objects not being closed properly - this is generally due to a call to clone() without a subsequent call to close() on *both* tuples.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Tracking this down is then a case of figuring out where the guilty tuples object was created, and then identifying where it should have been closed.
</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 #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 #15 (In Progress): Product of Sum form has very poor performance.https://code.mulgara.org/issues/152006-09-06T04:30:23ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">[[OrderedAppend]] currently assumes that all it's operands share a common ordering. This is currently guarenteed by [[TuplesOperations]].append(), but the use of calls to project() on all operands not matching the first's variable list. This has signifigant performance ramifications as the desired ordering is unknown until any parent-join is optimised.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Without the projections currently done by [[TuplesOperations]].append(), we need new logic in [[OrderedAppend]] to handle mapping variables to operands columns. This is not a problem unless there the disjunction is subject to a join containing a left-bound prefix including mismatched variables.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Consider the following tuple expressions:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
A[$z] ^ B( C[$z $y] v D[$y $z] )
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Note:
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>A[] will provide $z prefix to B[].
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>B[] currently passes this on blindly to C[] and D[].
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>This will bind $z for $y in D[], leading to an incorrect result.
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>Currently the non-union compatible
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>Fixing this will require either reordering D[], or filtering it; deciding between them is a performance optimisation issue.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
A[$y $z] ^ B(C[$y] v D[$z])
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Note:
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>Here there is a full prefix provided by A[] to B[].
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>The prefix needs to be decomposed for C[] and D[]
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>This is a case of non-union compatible disjunction, and will probably result in UNBOUND's.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Cases where this is probably a problem:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
non-symmetric sum-of-products (ie. {$a <span class="ni">&lt;</span>foo<span class="ni">&gt;</span> $b ^ $b <span class="ni">&lt;</span>bar<span class="ni">&gt;</span> $c in <span class="ni">&lt;</span>m1<span class="ni">&gt;</span>} v {$b <span class="ni">&lt;</span>bar<span class="ni">&gt;</span> $c ^ $a <span class="ni">&lt;</span>foo<span class="ni">&gt;</span> $b in <span class="ni">&lt;</span>m2<span class="ni">&gt;</span>} )
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>Note: this is one of the key areas of concern. Differences between models can cause join-optimisation to generate a different ordering; This interferes with attempts to improve SOP performance which is required to support efficient views.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
symmetric disjunctions: (ie. $s <span class="ni">&lt;</span>foo<span class="ni">&gt;</span> $o v $o <span class="ni">&lt;</span>bar<span class="ni">&gt;</span> $s). - uncommon.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
non-union compatible disjunction (ie. $s <span class="ni">&lt;</span>name<span class="ni">&gt;</span> $name v $s <span class="ni">&lt;</span>email<span class="ni">&gt;</span> $email)
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>Note: this query is better phrased as a subquery anyway.
</code></pre>