Mulgara Project: Issueshttps://code.mulgara.org/https://code.mulgara.org/favicon.ico?15861924492008-05-19T00:38:16ZMulgara Project
Redmine Mulgara - Feature #122 (Closed): Support XAResource.setTransactionTimeouthttps://code.mulgara.org/issues/1222008-05-19T00:38:16Zronald -ronald@foo.bar
<p><code>MulgaraXAResource</code> currently ignores the timeout and returns false. Instead<br />it should set the underlying transaction timeout.</p>
<p>This depends on <a class="issue tracker-9 status-27 priority-27 priority-high3 closed" title="Feature: Abort idle transactions on timeout (Closed)" href="https://code.mulgara.org/issues/121">#121</a> for complete functionality.</p> Mulgara - Feature #121 (Closed): Abort idle transactions on timeouthttps://code.mulgara.org/issues/1212008-05-19T00:33:42Zronald -ronald@foo.bar
<p>If a client goes away while holding the write lock, the write lock is<br />never released, leading to mulgara being locked forever. Currently the<br />timeout "only" sets the timeout on the internal transaction manager<br />which just causes the transaction to be marked for rollback on a<br />timeout. However, setting the timeout should also start a timer which<br />is used to abort a non-active transaction (this should happened for<br />both read-write as well as read-only transactions as the latter could<br />be holding on to a phase, leading to a "memory leak").</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 - 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 #84 (Closed): Review and Test JTA Branchhttps://code.mulgara.org/issues/842008-03-08T02:13:58ZAndrae Muys -andrae@netymon.com
<p>Code-review and testing for the JTA Implementation</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 - Bug #70 (Closed): Using a database-session in multiple threads can deadlock the serverhttps://code.mulgara.org/issues/702007-09-11T10:56:51Zronald -ronald@foo.bar
<pre>
<code class="html syntaxhl">We have a shutdown handler on the client that closes open sessions;
<span class="nt"><br/></span>
however, this shutdown handler is run is separate thread of its own.
<span class="nt"><br/></span>
So an abort of the client while it's doing a db operation can generate
<span class="nt"><br/></span>
the following sequence of events which leads to a deadlock:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
{noformat}
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>Thread-1 Thread-2
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>set autocommit off
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>...
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>insert ... close()
<span class="nt"><br/></span>
{noformat}
<span class="nt"><br/></span>
<span class="nt"><br/></span>
(i.e. the insert and the close happen almost simultaneously). The
<span class="nt"><br/></span>
resulting stack traces are roughly:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
{noformat}
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>Thread-1:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>DatabaseSession.insert()
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>DatabaseSession.execute()
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>MulgaraTransaxction.execute()
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>MulgaraTransaction.deactivate() <span class="ni">&lt;</span>---- monitor held
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>MulgaraTransaction.commitTransation()
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>MulgaraTransactionManager.transacactionComplete()
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>MulgaraTransactionManager.acquireMutex() <span class="ni">&lt;</span>--- blocked
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>Thread-2:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>DatabaseSession.close()
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>MulgaraTransactionManager.rollbackCurrentTransactions()
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>MulgaraTransactionManager.acquireMutex() <span class="ni">&lt;</span>--- mutex held
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>MulgaraTransaction.execute()
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>MulgaraTransaction.activate() <span class="ni">&lt;</span>--- blocked
<span class="nt"><br/></span>
{noformat}
<span class="nt"><br/></span>
<span class="nt"><br/></span>
</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 #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 - Bug #44 (Closed): Error during transaction.commit() causes infinite recursion and loopinghttps://code.mulgara.org/issues/442007-02-25T09:13:24Zronald -ronald@foo.bar
<pre>
<code class="html syntaxhl">This is svn head (rev <span class="nt"><a</span> <span class="na">href=</span><span class="s">"http://mulgara.org/trac/changeset/189"</span><span class="nt">></span>189<span class="nt"></a></span>), i.e. with the new transaction code.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Here's a small snippet of the stack when the error is triggered:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>at org.objectweb.jotm.TransactionImpl.commit(TransactionImpl.java:222)
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>at org.mulgara.resolver.MulgaraTransaction.terminateTransaction(MulgaraTransaction.java:330)
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>at org.mulgara.resolver.MulgaraTransaction.deactivate(MulgaraTransaction.java:154)
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>at org.mulgara.resolver.MulgaraTransaction.execute(MulgaraTransaction.java:207)
<span class="nt"><br/></span>
<span class="nt"><br/></span>
If commit() throws an exception, implicitRollback() will be invoked at
<span class="nt"><br/></span>
line 333, which in turn call checkActivated() on line 262, which in
<span class="nt"><br/></span>
turn calls implicitRollback() on line 442 because inuse is 0 (from
<span class="nt"><br/></span>
deactivate()).
<span class="nt"><br/></span>
<span class="nt"><br/></span>
At this point things go horribly wrong...
<span class="nt"><br/></span>
<span class="nt"><br/></span>
An easy way to trigger this is run out of disk space where the db
<span class="nt"><br/></span>
resides (e.g. on linux create a fs on a small file and mount using the
<span class="nt"><br/></span>
loop device: 'dd if=/dev/zero of=/tmp/mdb bs=4096 count=1000',
<span class="nt"><br/></span>
'mke2fs /tmp/mdb', 'mount -o loop /tmp/mdb /mnt/disk').
<span class="nt"><br/></span>
<span class="nt"><br/></span>
</code></pre> Mulgara - Bug #38 (Closed): starting transaction does not create a sessionhttps://code.mulgara.org/issues/382006-12-04T18:35:45Zalexcozzi -alexcozzi@foo.bar
<pre>
<code class="html syntaxhl">The following code causes a null pointer exception at the <span class="ni">&quot;&quot;</span>beginTransaction<span class="ni">&quot;</span> command.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
[[ItqlInterpreterBean]] bean = new [[ItqlInterpreterBean]]();
<span class="nt"><br/></span>
String insertText = <span class="ni">&quot;</span>insert <span class="ni">&lt;</span>urn:alex<span class="ni">&gt;</span> <span class="ni">&lt;</span>urn:name<span class="ni">&gt;</span> 'alex cozzi' into <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"rmi://localhost/server1#sampledata&gt;;"</span><span class="nt">></span>rmi://localhost/server1#sampledata<span class="ni">&amp;</span>gt;;<span class="nt"></a></span><span class="ni">&quot;</span>;
<span class="nt"><br/></span>
bean.beginTransaction(<span class="ni">&quot;</span>insertion<span class="ni">&quot;</span>);
<span class="nt"><br/></span>
bean.executeUpdate(insertText);
<span class="nt"><br/></span>
bean.commit(<span class="ni">&quot;</span>insertion<span class="ni">&quot;</span>);
<span class="nt"><br/></span>
<span class="nt"><br/></span>
If I use the bean before calling beginTransaction then everything is fine. Another workaound is to use
<span class="nt"><br/></span>
bean.setServerURI(<span class="ni">&quot;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"rmi://localhost/server1"</span><span class="nt">></span>rmi://localhost/server1<span class="nt"></a></span><span class="ni">&quot;</span>);
<span class="nt"><br/></span>
before calling beginTransaction.
</code></pre> Mulgara - Feature #37 (Closed): Lock-splitting required for MulgaraTransactionManagerhttps://code.mulgara.org/issues/372006-12-04T05:15:18ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">While documenting the new transaction work I noticed that the read-only and read-write paths through the Manager share the came lock - the manager just uses synchronized methods (ie. is a monitor).
<span class="nt"><br/></span>
<span class="nt"><br/></span>
As read-write transactions can block for a substantial duration during a commit, while the block-cache is flushed to disk, they should not hold the same lock as the read-only methods require to initate read-transactions while this is happening.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
The solution is to introduce two locks independent of the manager's monitor lock.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
1. Covering alterations to the transaction metadata held in the manager, all of which are simple O(1) operations.
<span class="nt"><br/></span>
2. Covering alterations to the write-lock/writing-session metadata, which must be held over a commit().
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Deadlock is not possible as the 2nd lock is only obtained by sessions wishing to obtain the writelock.
<span class="nt"><br/></span>
</code></pre> Mulgara - Bug #36 (Closed): Basic query failurehttps://code.mulgara.org/issues/362006-11-20T23:50:01Zronald -ronald@foo.bar
<pre>
<code class="html syntaxhl">The following setup demonstrates the problem:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>drop <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///topazproject#test&gt;;"</span><span class="nt">></span>local:///topazproject#test<span class="ni">&amp;</span>gt;;<span class="nt"></a></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>create <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///topazproject#test&gt;;"</span><span class="nt">></span>local:///topazproject#test<span class="ni">&amp;</span>gt;;<span class="nt"></a></span>
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>insert
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;</span>foo:bar<span class="ni">&gt;</span> <span class="ni">&lt;</span>foo:set<span class="ni">&gt;</span> <span class="ni">&lt;</span>user:joe<span class="ni">&gt;</span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;</span>foo:set<span class="ni">&gt;</span> <span class="ni">&lt;</span>topaz:implies<span class="ni">&gt;</span> <span class="ni">&lt;</span>bar:set<span class="ni">&gt;</span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;</span>foo:set<span class="ni">&gt;</span> <span class="ni">&lt;</span>topaz:implies<span class="ni">&gt;</span> <span class="ni">&lt;</span>bar:get<span class="ni">&gt;</span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>into <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///topazproject#test&gt;;"</span><span class="nt">></span>local:///topazproject#test<span class="ni">&amp;</span>gt;;<span class="nt"></a></span>
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>select $s $p $o from <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///topazproject#test"</span><span class="nt">></span>local:///topazproject#test<span class="nt"></a></span><span class="ni">&gt;</span> where (
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>$s $p $o
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>and ($s <span class="ni">&lt;</span>mulgara:is<span class="ni">&gt;</span> <span class="ni">&lt;</span>foo:bar<span class="ni">&gt;</span>)
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>) or (
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>($s $impliedBy $o and $impliedBy <span class="ni">&lt;</span>topaz:implies<span class="ni">&gt;</span> $p)
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>and ($s <span class="ni">&lt;</span>mulgara:is<span class="ni">&gt;</span> <span class="ni">&lt;</span>foo:bar<span class="ni">&gt;</span>)
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>);
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>select $s $p $o from <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///topazproject#test"</span><span class="nt">></span>local:///topazproject#test<span class="nt"></a></span><span class="ni">&gt;</span> where (
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>$s $p $o
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>or ($s $impliedBy $o and $impliedBy <span class="ni">&lt;</span>topaz:implies<span class="ni">&gt;</span> $p)
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>) and ($s <span class="ni">&lt;</span>mulgara:is<span class="ni">&gt;</span> <span class="ni">&lt;</span>foo:bar<span class="ni">&gt;</span>);
<span class="nt"><br/></span>
<span class="nt"><br/></span>
The two queries are logically equivalent (the <span class="ni">&lt;</span>mulgara:is<span class="ni">&gt;</span> term is duplicated in the first query, and factored out in the second query). However, while the first query returns three statements, the second query only returns one. Specifically, the first query returns
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&lt;</span>foo:bar<span class="ni">&gt;</span> <span class="ni">&lt;</span>foo:set<span class="ni">&gt;</span> <span class="ni">&lt;</span>user:joe<span class="ni">&gt;</span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&lt;</span>foo:bar<span class="ni">&gt;</span> <span class="ni">&lt;</span>bar:set<span class="ni">&gt;</span> <span class="ni">&lt;</span>user:joe<span class="ni">&gt;</span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&lt;</span>foo:bar<span class="ni">&gt;</span> <span class="ni">&lt;</span>bar:get<span class="ni">&gt;</span> <span class="ni">&lt;</span>user:joe<span class="ni">&gt;</span>
<span class="nt"><br/></span>
<span class="nt"><br/></span>
but the second returns only
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&lt;</span>foo:bar<span class="ni">&gt;</span> <span class="ni">&lt;</span>foo:set<span class="ni">&gt;</span> <span class="ni">&lt;</span>user:joe<span class="ni">&gt;</span>
<span class="nt"><br/></span>
<span class="nt"><br/></span>
</code></pre> Mulgara - Bug #34 (Closed): NUC-disjunction fails when one term is unconstrained.https://code.mulgara.org/issues/342006-11-14T04:02:50Zronald -ronald@foo.bar
<pre>
<code class="html syntaxhl">The following is a minimal example that triggers the bug:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>create <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///topazproject#test&gt;;"</span><span class="nt">></span>local:///topazproject#test<span class="ni">&amp;</span>gt;;<span class="nt"></a></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>insert
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;</span>foo:one<span class="ni">&gt;</span> <span class="ni">&lt;</span>p:type<span class="ni">&gt;</span> <span class="ni">&lt;</span>t:p<span class="ni">&gt;</span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;</span>foo:one<span class="ni">&gt;</span> <span class="ni">&lt;</span>p:hasA<span class="ni">&gt;</span> <span class="ni">&lt;</span>bar:one<span class="ni">&gt;</span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;</span>foo:one<span class="ni">&gt;</span> <span class="ni">&lt;</span>p:hasB<span class="ni">&gt;</span> 'mollusks'
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;</span>foo:two<span class="ni">&gt;</span> <span class="ni">&lt;</span>p:type<span class="ni">&gt;</span> <span class="ni">&lt;</span>t:p<span class="ni">&gt;</span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;</span>foo:two<span class="ni">&gt;</span> <span class="ni">&lt;</span>p:hasA<span class="ni">&gt;</span> <span class="ni">&lt;</span>bar:two<span class="ni">&gt;</span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;</span>foo:two<span class="ni">&gt;</span> <span class="ni">&lt;</span>p:hasB<span class="ni">&gt;</span> 'mollusks'
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>into <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///topazproject#test&gt;;"</span><span class="nt">></span>local:///topazproject#test<span class="ni">&amp;</span>gt;;<span class="nt"></a></span>
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>select $a $t from <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///topazproject#test"</span><span class="nt">></span>local:///topazproject#test<span class="nt"></a></span><span class="ni">&gt;</span> where
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>$b <span class="ni">&lt;</span>p:type<span class="ni">&gt;</span> <span class="ni">&lt;</span>t:p<span class="ni">&gt;</span> and
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>$b <span class="ni">&lt;</span>p:hasA<span class="ni">&gt;</span> $a and
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>(
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>($b <span class="ni">&lt;</span>p:hasB<span class="ni">&gt;</span> 'mollusks' and $t <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"http://mulgara.org/mulgara#is"</span><span class="nt">></span>http://mulgara.org/mulgara#is<span class="nt"></a></span><span class="ni">&gt;</span> '0')
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>or
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>($t <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"http://mulgara.org/mulgara#is"</span><span class="nt">></span>http://mulgara.org/mulgara#is<span class="nt"></a></span><span class="ni">&gt;</span> '1')
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>);
<span class="nt"><br/></span>
<span class="nt"><br/></span>
The result is
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>QueryException thrown in resolve:
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>org.mulgara.query.QueryException: Failed to resolve query
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>Caused by: org.mulgara.query.TuplesException: Prefix failed to meet defined minimum prefix
<span class="nt"><br/></span>
</code></pre> Mulgara - Bug #33 (Closed): can create same model twice with different typeshttps://code.mulgara.org/issues/332006-11-13T06:59:54Zronald -ronald@foo.bar
<pre>
<code class="html syntaxhl">The following is accepted by mulgara:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>create <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///foo#m1&gt;;"</span><span class="nt">></span>local:///foo#m1<span class="ni">&amp;</span>gt;;<span class="nt"></a></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>create <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///foo#m1"</span><span class="nt">></span>local:///foo#m1<span class="nt"></a></span><span class="ni">&gt;</span> <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"http://mulgara.org/mulgara#XMLSchemaModel&gt;;"</span><span class="nt">></span>http://mulgara.org/mulgara#XMLSchemaModel<span class="ni">&amp;</span>gt;;<span class="nt"></a></span>
<span class="nt"><br/></span>
<span class="nt"><br/></span>
This then results in a partially unusable database, as this
<span class="nt"><br/></span>
error cannot be corrected anymore. E.g.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>drop <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///foo#m1&gt;;"</span><span class="nt">></span>local:///foo#m1<span class="ni">&amp;</span>gt;;<span class="nt"></a></span>
<span class="nt"><br/></span>
<span class="nt"><br/></span>
produces the error
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>Error resolving [$s $p $o $_from] from <span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///foo#m1"</span><span class="nt">></span>local:///foo#m1<span class="nt"></a></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>Model 287 has more than one type!
<span class="nt"><br/></span>
<span class="nt"><br/></span>
It would be more robust if the 'create' checked that the model type
<span class="nt"><br/></span>
is the same in the case where the model already exists.
<span class="nt"><br/></span>
</code></pre>