Mulgara Project: Issueshttps://code.mulgara.org/https://code.mulgara.org/favicon.ico?15861924492008-03-28T04:22:27ZMulgara Project
Redmine Mulgara - Feature #94 (New): On insert/delete inferencing resolver (triggers)https://code.mulgara.org/issues/942008-03-28T04:22:27ZAndrae Muys -andrae@netymon.com
<p>Migrated from the Kowari RFE List</p>
<p>A Resolver that wraps the store and can read a basic<br />inferencing ruleset and insert/delete multiple<br />statements in/from the store in response to each<br />statement passed to modify.</p>
<p>This should include a <a class="wiki-page new" href="https://code.mulgara.org/projects/mulgara/wiki/ContentHandler">ContentHandler</a> that can parse<br />it's config file into rdf so the rules can be stored in<br />a ?def model in the system-store. It would be<br />important to be able to include by reference an<br />external config-file (accessed via the <a class="wiki-page new" href="https://code.mulgara.org/projects/mulgara/wiki/ContentHandler">ContentHandler</a>).</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 #62 (New): Revisit Operation.preExecute()https://code.mulgara.org/issues/622007-05-07T04:34:09ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">See setModel in [[DatabaseSession]] for use - this is an unpleasant non-orthoginality.
</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 #53 (New): FileSystemResolver keeps exhausting heaphttps://code.mulgara.org/issues/532007-03-20T03:51:53ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">Regularly seeing heap exhaustion when running the [[FileSystemResolver]] unit test.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
I believe this resolver is memory bound and needs to be modified to use disk-backed structures.
</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 #31 (New): resolveVariableModel does not check securityAdaptorListhttps://code.mulgara.org/issues/312006-11-10T07:01:02ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">This allows queries containing variable models to bypass the security layer.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Mulgara currently doesn't have any security modules in its distribution - so this code path is currently only used by various unit-tests. This bug must be fixed when we come to implement security modules.
</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 #26 (New): Remove getElement() from the Constraint interface - An easy fix, no ...https://code.mulgara.org/issues/262006-10-03T06:30:07ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">Back in the distant past when the only type of Constraint supported was what we now refer to as [[ConstraintImpl]], getElement() was an ugly, but harmless way of obtaining the different elements of a constraint.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Now that we have dozens of different constraint types, the vast majority of which have to implement getElement() by throwing an exception, this is not so harmless.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
It would be great if someone could go through the codebase and:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
1) Add getSubject(), getPredicate(), and getObject() to [[ConstraintImpl]]
<span class="nt"><br/></span>
2) Find each call to [[ConstraintImpl]]::getElement(), and replace with the appropriate call (element 0-<span class="ni">&gt;</span>subject, 1-<span class="ni">&gt;</span>predicate, 2-<span class="ni">&gt;</span>object; 3-<span class="ni">&gt;</span>model but that should already have been done).
<span class="nt"><br/></span>
3) Repeat for [[ConstraintNegation]] (and any other constraint type that implements getElement(), but IIRC there aren't any).
<span class="nt"><br/></span>
4) Remove getElement() from the Constraint interface and implementing classes thereby banishing this aberration.
</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 #20 (New): Provide full client-side jrdf supporthttps://code.mulgara.org/issues/202006-09-14T04:54:08ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">Depends on fixing transactions to support read-only transactions.
</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 - Feature #16 (In Progress): Add Rules for OWL DL/Full supporthttps://code.mulgara.org/issues/162006-09-14T04:28:54ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">Extend the new Rules Engine to support OWL Full.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Provide rule sets for OWL DL and OWL Full.
</code></pre>