[jira] [Commented] (CLEREZZA-603) EzMGraph fails when working with more than one instance

["Henry Story (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CLEREZZA-603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063345#comment-13063345 ] 

Henry Story commented on CLEREZZA-603:
--------------------------------------

I have made the changes in github in the zz-issues branch:

https://github.com/bblfish/clerezza/commit/85628443598eaf817f0b20809cc7c5f6916a7f82

> 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
>   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