[
https://issues.apache.org/jira/browse/CLEREZZA-603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063414#comment-13063414
]
Reto Bachmann-Gmür commented on CLEREZZA-603:
---------------------------------------------
Your code is calling b_ on an explicitely specified EzMGraph, All the examples
should shows usage that either subclass EzMGraph to create an instance or set
the context to specific graph by importing the methods of an EzMGraph instance,
but I see the method coud be improved not to require implict conversions thus
allowing usage as you describe (have b_ return a (Rich)GraphNode rather than a
bnode.
put the patched version in the svn folder issues/CLEREZZA-603?
Cheers,
Reto
> 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
