I left this issue alone for a couple of weeks as 3.0.2 was looming. Here's my summary of where the discussion went:
1. Bryn liked the idea of maintaining a strong hierarchy for close() 2. I mentioned that the strong hierarchy is intuitive, but would place burden on providers and complicate code considerably. 3. Pieter Martin explained what sqlg does on close() which immediately introduced a break to a strong hierarchy (a pattern I think we would see across providers in various ways). I think that we should move in favor of implementing AutoCloseable where it makes sense to release resources and not force a strict hierarchy. This places some burden on users to know how/when to close things, but if we document carefully we can mitigate that issue. If no-one objects within 72 hours, I'll assume lazy consensus and move in that fashion to get those JIRA tickets closed for 3.1.0. On Wed, Oct 7, 2015 at 8:57 AM, Stephen Mallette <[email protected]> wrote: > I'm fine with all items in the Graph hierarchy implementing AutoCloseable > (including GraphTraversal). I'm not sure what the implementation would > look like though and what it would do. Perhaps I'll take a look at > ResourceIterator from Neo4j. If we go with the idea that the user is > responsible for properly closing things and close() on each component works > in this independent fashion, then we can fire up a separate discussion for > what close() on GraphTraversal means (and each item in the Graph > hierarchy). Sounds like you're in favor of this approach - i guess we'll > see if anyone else has other opinions. > > On Wed, Oct 7, 2015 at 8:34 AM, pieter-gmail <[email protected]> > wrote: > >> Ok, how about making GraphTraversal implement AutoCloseable? >> >> Thanks >> Pieter >> >> On 07/10/2015 14:28, Stephen Mallette wrote: >> > n I think the best approach is to leave it to users to close() >> > resources properly and keep document it as a convention. So Option 2 >> from >> > my initial post in this >> >> >
