EzMGraph fails when working with more than one instance
-------------------------------------------------------
Key: CLEREZZA-603
URL: https://issues.apache.org/jira/browse/CLEREZZA-603
Project: Clerezza
Issue Type: Bug
Reporter: Henry Story
Priority: Critical
All the EzMGraph test cases currently assume that there is only one ez graph
available per method.
When one adds two EzMGraphs together in some code one gets a failure as the
following test case shows when run in EzMGraphTest class:
@Test
def twographs {
val ez1 = new EzMGraph() {(
b_("reto") -- FOAF.name --> "Reto
Bachman-Gmür".lang("rm")
)}
Assert.assertEquals("the two graphs should be equal",1,ez1.size)
import ez1._
ez1.b_("reto") -- FOAF.homepage --> "http://bblfish.net/".uri
Assert.assertEquals("ez1 has grown by one",2,ez1.size)
//now a second graph
val ez2 = new EzMGraph() {(
b_("hjs") -- FOAF.name --> "Henry Story"
)}
ez2.b_("hjs") -- FOAF.homepage --> "http://bblfish.net/".uri
//both of these tests fail
Assert.assertEquals("ez1 is the same size as it used to
be",2,ez1.size)
Assert.assertEquals("ez2 has grown by one",2,ez2.size)
}
This is caused by a bit too much implicit magic. EzMGraph extends
TcDependentConversions which is defined as
protected trait TcDependentConversions {
def baseTc: TripleCollection
implicit def toRichGraphNode(resource: Resource) = {
new RichGraphNode(new GraphNode(resource, baseTc))
}
}
So when developing this one has to import the toRichGraphNode method for the
TripleCollection one is using.
Hence you will see the first
import ez1._
above. The errors can be avoided if one enters a new import for ez2._ just
before code using ez2 . The problem is that this will never be picked up by the
compiler and the error will only be found at runtime. But then code would look
like this
import ez1._
ez1.b_("reto") -- FOAF.homepage --> "http://bblfish.net/".uri
import ez2._
ez2.b_("hjs") -- FOAF.homepage --> "http://bblfish.net/".uri
import ez1._
ez1.b_("reto") -- FOAF.currentProject -->
"http://clerezza.org/".uri
The answer to this problem is simply to have the ez1.b_ method return a
RichGraphNode directly containing the EzGraphNode from which it was called.
It makes more sense anyway to have a Graph return a GraphNode when one asks for
a node from it. Certainly a BNode outside of the context of a graph makes very
little sense.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
