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 #186 (Closed): SPARQL filters can't parse non-numeric comparisonshttps://code.mulgara.org/issues/1862009-03-06T22:07:30ZAlex Hall -alexhall@revelytix.com
<p>The inner classes of <a class="wiki-page new" href="https://code.mulgara.org/projects/mulgara/wiki/FilterMapper">FilterMapper</a>.java which handle parsing of >, >=, <, and <= operations coerce their arguments into numeric expressions, although the grammar should allow for any comparable expression type to appear here (and the corresponding filter operations in org.mulgara.query.filter allow for any comparable expression).</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 #135 (New): Mulgara keeps file lock if parsing of RDF/XML failshttps://code.mulgara.org/issues/1352008-07-29T20:48:41ZAlex Hall -alexhall@revelytix.com
<p>Running Mulgara 2.0.0 on Windows XP, if the parsing of an RDF/XML file fails due to illegal content during a load, Mulgara does not release the lock on that file.</p> Mulgara - Bug #125 (Closed): Configured transaction timeout is overridden with hard-coded valuehttps://code.mulgara.org/issues/1252008-05-20T21:20:49ZAlex Hall -alexhall@revelytix.com
<p>The transaction timeout for use with database transactions is configurable in the Mulgara config file. However, the configured transaction timeout is overridden with a hard-coded value of one hour in the <a class="wiki-page new" href="https://code.mulgara.org/projects/mulgara/wiki/DatabaseSession">DatabaseSession</a> constructor (DatabaseSession.java, line 238-239) :</p>
<pre>
<pre>
The hard-coded value of one hour is not long enough for loading very large files.</pre> Mulgara - Bug #124 (Closed): Load operation requires valid source URL even if overridden with Inp...https://code.mulgara.org/issues/1242008-05-20T21:14:20ZAlex Hall -alexhall@revelytix.com
<p>The org.mulgara.query.operation.Load class extends the <a class="wiki-page new" href="https://code.mulgara.org/projects/mulgara/wiki/DataTx">DataTx</a> operation, whose constructor requires URI's for source, destination, and graph. The <a class="wiki-page new" href="https://code.mulgara.org/projects/mulgara/wiki/DataTx">DataTx</a> operation also provides a setOverrideStream() method allowing the client to override the source URI with an <a class="wiki-page new" href="https://code.mulgara.org/projects/mulgara/wiki/InputStream">InputStream</a>. Even if an overriding input stream is used, the source URI is required to be a valid URL or else line 137 will throw an error. The line in question is:</p>
<pre>
I believe that the correct behavior if a client provides an overriding [[InputStream]] is to never evaluate the source URI and treat the input stream as always uncompressed.</pre> Mulgara - Bug #106 (Closed): ConnectionFactory caches closed connectionshttps://code.mulgara.org/issues/1062008-05-08T17:28:07ZAlex Hall -alexhall@revelytix.com
<p>The ConnectionFactory caches Connection objects based on server URI. If one process gets a connection to a server from the factory, operates on it, and closes the connection, then the next process that gets a connection to the same server from that factory will receive a connection that is already closed and therefore useless.</p> Mulgara - Bug #104 (Closed): Subtypes ignored in datatyped literal comparisonshttps://code.mulgara.org/issues/1042008-04-30T17:08:43ZAlex Hall -alexhall@revelytix.com
<p>When a new stringpool node is allocated (in XAStringPoolImpl.Phase.findGNode), the AVL comparator does not use the subtype ID locating the SPObject in the stringpool. If you attempt to insert a datatyped literal, and there is already a stringpool entry with an identical type ID and lexical form but different subtype ID, then the node for that existing entry is returned. For instance, if there is already an entry for <code>"0"^^xsd:integer</code>, you cannot insert <code>"0"^^xsd:nonNegativeInteger</code> -- it gets mapped to the existing <code>"0"^^xsd:integer</code>.</p>
<p>Fixing this issue would probably require modifying the comparator to use the subtype ID. This would have implications for any code that wants to take slices from the stringpool for typed literals, ignoring subtype (as I believe is the case in the XSD resolver). Also, changing the comparator would change the ordering in the stringpool, which would break backwards compatibility with previous database versions.</p>