Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use Jena's notion of graph containment instead of our strict equality #552

Merged
merged 1 commit into from Oct 17, 2014

Conversation

cbeer
Copy link
Contributor

@cbeer cbeer commented Oct 17, 2014

@@ -82,8 +97,8 @@ protected E computeNext() {
*
* @return The elements that turned out to be common to the two inputs.
*/
public Set<E> common() {
return source.hasNext() ? null : common;
public Iterator<Triple> common() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the advantage of returning the iterator here? Why not admit that the triples are in-heap and return the Graph? Are we just trying to avoid Jena types, 'cause I think it's too late for that... {grin}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the previous iteration of this commit, I thought you found Graph#find(null, null, null) in the FedoraResourceImpl distasteful.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, sorry to be unclear-- I was hoping for aCollection<Triple> here, because that makes it clear to the client that

  • this is in-memory stuff, with the attendant risks, and
  • you can iterate on it as much as you like.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm pretty sure that's not part of the Graph contract (because it's possible to not have a whole Graph in memory?).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I'm saying we actually fold up the Graph and return a non-Jena type. But this is, again, a question of just how much we're going to fight the Jena types percolating through our system. Maybe it's better to just go with this as it is, since I am going to come back at some point soon and factor equivalence out of this type anyway. That might be the time to worry more about it. {sigh}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd leave it for now; our one and only consumer then took the Set and turned it into an Iterator anyway.

awoods pushed a commit that referenced this pull request Oct 17, 2014
Use Jena's notion of graph containment instead of our strict equality
@awoods awoods merged commit 019365e into master Oct 17, 2014
@awoods awoods deleted the jena-graph-containment branch October 17, 2014 16:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants