[
https://issues.apache.org/jira/browse/CLEREZZA-603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063880#comment-13063880
]
Henry Story edited comment on CLEREZZA-603 at 7/12/11 1:48 PM:
---------------------------------------------------------------
attached patch
0001-CLEREZZA-603-EzMGraph.bnode-now-returns-a-RichGraphN.patch
produced following the method explained in http://www.apache.org/dev/git.html
was (Author: bblfish):
the patch produced following the method explained
http://www.apache.org/dev/git.html
> 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
> Attachments:
> 0001-CLEREZZA-603-EzMGraph.bnode-now-returns-a-RichGraphN.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> 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
