Mulgara Project: Issueshttps://code.mulgara.org/https://code.mulgara.org/favicon.ico?15861924492008-11-22T15:03:51ZMulgara Project
Redmine Mulgara - Feature #173 (Closed): Implement Accept headershttps://code.mulgara.org/issues/1732008-11-22T15:03:51ZPaula Gearon
<p>The web api current takes "out" as a parameter to define the return type. This should be implemented as a content type defined in the Accept header from the client. See:<br /> <a class="external" href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1">http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1</a></p>
<p>For ease of access with clients that set their own Accept types, the "out" parameter should continue to be accepted, but the name should change to something more sensible, like "type".</p> Mulgara - Feature #167 (Closed): Port RLog grammar to JavaCChttps://code.mulgara.org/issues/1672008-11-05T05:19:39ZPaula Gearon
<p>RLog was built in Beaver, as this was a learning exercise for a LALR parser. However, <a class="wiki-page new" href="https://code.mulgara.org/projects/mulgara/wiki/JavaCC">JavaCC</a> (an LL parser) is adequate to the task, and is already integrated for SPARQL.</p> Mulgara - Bug #155 (Closed): Allow relative URIs in querieshttps://code.mulgara.org/issues/1552008-10-17T22:21:50ZPaula Gearon
<p>Queries current check URIs to see if they are relative or absolute. This is down in the URIReference code, and should be avoided.</p> Mulgara - Feature #151 (Closed): Emulate graph indexes in XA 1.1https://code.mulgara.org/issues/1512008-10-15T00:05:37ZPaula Gearon
<p>XA 1 had the following indexes:<br /><pre>
GSPO
GPOS
GOSP
SPOG
POSG
OSPG
</pre></p>
<p>XA 1.1 is able to remove the last 3 indexes for most queries, but there are still some queries that require them. In these cases the effect of these indexes can be emulated by using the contents of the system graph. This requires the system resolver to correctly bootstrap itself, as it will need to interrogate itself for information that must be present before the emulation can occur.</p> Mulgara - Feature #148 (Closed): Remove Jena dependency in date typeshttps://code.mulgara.org/issues/1482008-09-19T21:03:12ZPaula Gearon
<p>The date types of gYear, gMonth, gDay, gMonthDay and gYearMonth are using Jena XSD classes to wrap the fields in a java.util.Calendar object, despite parsing everything themselves. The work is redundant, and it is creating an artificial dependence on Jena code. This should be removed.</p> Mulgara - Feature #145 (Closed): Remove WebUIhttps://code.mulgara.org/issues/1452008-08-30T06:02:09ZPaula Gearon
<p>Remove the <a class="wiki-page" href="https://code.mulgara.org/projects/mulgara/wiki/WebUI">WebUI</a> webapp. Importantly, this also requires the removal of the barracuda jars, and xmlc-*.jar.</p> Mulgara - Feature #144 (Closed): Set root of web server to redirect to webclienthttps://code.mulgara.org/issues/1442008-08-30T02:47:19ZPaula Gearon
<p>If the root path of the Jetty web server is accessed it currently gives a 404. This should redirect to:<br /><a class="external" href="http://servername:8080/webquery">http://servername:8080/webquery</a></p> Mulgara - Feature #143 (Closed): Integrate SPARQLhttps://code.mulgara.org/issues/1432008-08-29T05:05:04ZPaula Gearon
<p>The SPARQL parser is implemented in a separate project. This is inconvenient, both for following the source, and for updating with new features, such as SPARQL/Update.</p>
<p>The original idea was to keep this functionality as modularized as possible, allowing it to be used for other projects as well (since other libraries that profess to do this are often too tied to a particular implementation). However, this is not really necessary, as it is unlikely to ever be used this way.</p> Mulgara - Feature #141 (Closed): Need new backup format for XA 1.1 data poolhttps://code.mulgara.org/issues/1412008-08-25T18:13:17ZPaula Gearon
<p>The current backup/restore is designed for XA 1. This has issues for XA 1.1.</p>
<p>The fix described in <a class="issue tracker-9 status-27 priority-27 priority-high3 closed" title="Feature: Backup/Restore for XA 1.1 Data Pool (Closed)" href="https://code.mulgara.org/issues/140">#140</a> will make the XA 1.1 backup/restore work on V6 backups files (compatible with the latest XA 1 backup). However, it will be inefficient. A new backup format is needed for efficient backup/restore of XA 1.1.</p>
<p>The new format is not going to supplant XA 1, so it should not be labeled V7. It may be possible to call it "V6.1" though a disconnected numbering scheme would be preferable.</p>
<p>It should not be necessary to make the new format readable by XA 1, but this should be relatively easy, either using the IntFile mapping suggested in <a class="issue tracker-9 status-27 priority-27 priority-high3 closed" title="Feature: Backup/Restore for XA 1.1 Data Pool (Closed)" href="https://code.mulgara.org/issues/140">#140</a>, or just by specifying gNodes, since this format allows gNodes to be specified. The latter is less desirable, as it can lead to files growing larger than they should in the XA 1 format.</p> Mulgara - Bug #139 (Closed): base64 encoding for XA 1.1 String Poolhttps://code.mulgara.org/issues/1392008-08-25T17:26:38ZPaula Gearon
<p>The scripted TQL tasks failed to return some data that was encoded with base64. This may be something in the string pool or some strange interaction with something else, as I haven't looked too closely at it yet. Every other data type appears OK, so far.</p>
<p>The problem appears in the tests in jxtest/iTQL/data_types/binary/base64Binary. The third test should give the results in queryResult3.txt, but the results are instead empty (the result is still well formatted, but contains an empty set).</p> Mulgara - Bug #107 (Closed): XMLLiterals have heavy validationhttps://code.mulgara.org/issues/1072008-05-12T21:59:11ZPaula Gearon
<p>The factory for XMLLiterals pastes the text into a stub of RDF and runs the parser against it. This can fail in Eclipse if serializer-ver.jar is not in the classpath. More importantly, this is expensive, and unnecessary when loading the datum out of the string pool.</p>
<p>The validation should be reviewed, and completely avoided for loading from the string pool.</p>
<p>See org.mulgara.store.stringpool.xa.SPXMLLiteralImpl.validate(String):101 for details.</p> Mulgara - Feature #105 (Closed): Duplicate variables in BGPs can be handled in algebrahttps://code.mulgara.org/issues/1052008-05-08T06:06:17ZPaula Gearon
<pre>
Instead, successive instances of the same variable should be renamed, and the constraint should be conjoined with itself with the repeated variables rotated around.
e.g. for 2 variables:
{?x ?x ?y} becomes: {?x ?x2 ?y} AND {?x2 ?x ?y}
{?x ?y ?x} becomes: {?x ?y ?x2} AND {?x2 ?y ?x}
{?y ?x ?x} becomes: {?y ?x ?x2} AND {?y ?x2 ?x}
and for 3 variables:
{?x ?x ?x} becomes: {?x ?x2 ?x3} AND {?x3 ?x ?x2} AND {?x2 ?x3 ?x}
The values of ?x2 and ?x3 can always be ignored since they are identical to ?x.</pre> Mulgara - Bug #93 (Closed): Console re-running commandshttps://code.mulgara.org/issues/932008-03-26T22:57:23ZPaula Gearon
<p>If a command is incomplete on the console (no ; character) then the previous successful command can be run instead.</p> Mulgara - Bug #80 (Closed): RMI port change not possiblehttps://code.mulgara.org/issues/802008-02-07T16:52:55ZPaula Gearon
<p>When RMIServer starts up it attempts to use an <a class="wiki-page new" href="https://code.mulgara.org/projects/mulgara/wiki/InitialContext">InitialContext</a> that has a PROVIDER_URL set to <strong>rmi://localhost</strong>. However, this is never updated for those occasions when the port has been configured differently, so the RMI service is not allowed to start in these conditions.</p>
<p>Pulling apart the URL to check if it is correct cannot be done by default for URLs with the RMI protocol. Either the URL string has to be parsed manually, or else a protocol handler needs to be registered for RMI. Since we use RMI URLs in a number of places, it seems to make sense to create the handler, making these legal to create.</p> Mulgara - Bug #7 (Closed): Xalan missing in Java 1.5https://code.mulgara.org/issues/72006-07-10T04:47:59ZPaula Gearon
<pre>
<code class="html syntaxhl">src/jar/descriptor/src/java/org/mulgara/descriptor/DescriptorElement.java uses classes from org.apache.xalan.templates.
<span class="nt"><br/></span>
This package was included in Java 1.4, but not in Java 1.5. The library needs to be brought in manually.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
The bug does not show up on a Mac, as apple have included the package in the jar file:
<span class="nt"><br/></span>
/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/.compatibility/14compatibility.jar
</code></pre>