I have something that fixes OLTP. I haven't worked with OLAP and it looks like 
the changes for this will be extensive, touching IteratorUtils and so on.

Would you be interested in a PR for just the OLTP part?


-----Original Message-----
From: Stephen Mallette [mailto:[email protected]]
Sent: Wednesday, January 25, 2017 3:58 PM
To: [email protected]
Subject: Re: [DISCUSS] Release 3.2.4 and 3.1.6

in his case, it should go to tp32.

On Wed, Jan 25, 2017 at 3:56 PM, Paul A. Jackson <[email protected]>
wrote:

> For what branch should a pull request be submitted?
>
>
> -----Original Message-----
> From: Stephen Mallette [mailto:[email protected]]
> Sent: Wednesday, January 25, 2017 3:41 PM
> To: [email protected]
> Subject: Re: [DISCUSS] Release 3.2.4 and 3.1.6
>
> I went with the most obvious implementation place for CloseableIterator.
> If you see other spots where you could make an argument that it would
> make sense to add it then feel free to offer a pull request and we can
> get it reviewed. I didn't look into your VertexStep suggestion too
> deeply, but a quick review seems to have me thinking that it would make sense 
> to do that.
> Basically anywhere that a step interacts with the structure API seems
> like it would be a candidate for CloseableIterator to be implemented
> as it is in GraphStep.
>
> On Wed, Jan 25, 2017 at 3:30 PM, Paul A. Jackson <[email protected]>
> wrote:
>
> > So, I modified my code to work with CloseableIterator. I was hoping
> > this would be honored in more places than it is.
> >
> > Where it does work is if the user of a traversal calls
> > traversal.close() all the steps will get closed, including the
> > typically
> first GraphStep.
> > GraphStep in turn checks whether the iterator that was provided by
> > iteratorSupplier implements CloseableIterator and if so, closes it,
> > and this is good.
> >
> > What I was hoping, in addition, though, was when
> > VertexStep.flatMap() (or anything else) calls Vertex.vertices() or
> > Vertex.edges() that before it finishes with the iterator it also
> > make the same check for CloseableIterator and call close().
> >
> > Thoughts?
> >
> > -Paul
> >
> > -----Original Message-----
> > From: Paul A. Jackson [mailto:[email protected]]
> > Sent: Tuesday, January 24, 2017 3:01 PM
> > To: [email protected]
> > Subject: RE: [DISCUSS] Release 3.2.4 and 3.1.6
> >
> > Great. I'll try it out.
> >
> > -Paul
> >
> >
> > -----Original Message-----
> > From: Stephen Mallette [mailto:[email protected]]
> > Sent: Tuesday, January 24, 2017 2:54 PM
> > To: [email protected]
> > Subject: Re: [DISCUSS] Release 3.2.4 and 3.1.6
> >
> > no - it's in 3.2.4 and merged forward to 3.3.0:
> >
> > https://github.com/apache/tinkerpop/blob/e3889bf2401b42c3afbc85eabc2
> > fb c ebf2588974/gremlin-core/src/main/java/org/apache/
> > tinkerpop/gremlin/structure/util/CloseableIterator.java
> >
> > On Tue, Jan 24, 2017 at 2:52 PM, Paul A. Jackson
> > <[email protected]>
> > wrote:
> >
> > > Is CloseableIterator only in the 3.3 branch?
> > >
> > > -Paul
> > >
> > >
> > > -----Original Message-----
> > > From: Stephen Mallette [mailto:[email protected]]
> > > Sent: Monday, January 23, 2017 9:58 AM
> > > To: [email protected]
> > > Subject: [DISCUSS] Release 3.2.4 and 3.1.6
> > >
> > > It's been a while since we've had a release (October 2016) and
> > > given the importance of the recent critical security fix from
> > > Groovy 2.4.8 I think it's worth getting some new versions out
> > > there. I'm not sure what everyone is working on or has concerns
> > > about, but after the PRs that are out there for tp32 get merged
> > > (especially https://github.com/apache/
> > > tinkerpop/pull/541)
> > > I don't really have anything else critical for those versions.
> > > Please call out any issues that might be important for this
> > > release on this
> > thread.
> > >
> > > I don't think we should worry about doing a milestone release of
> > > 3.3.0
> > yet.
> > > I'd like to see some more change go into that branch before we do
> > > that, but if others feel differently and would like to offer an
> > > argument I'd be open to the idea.
> > >
> > > I propose we focus on a release of 3.1.6 and 3.2.4 in two weeks
> > > time with the code freeze going into place at end of day friday of
> > > this week (January 27, 2017). If there are no objections in the
> > > next three days (Thursday, January 26, 2017, 10:00am), let's
> > > assume lazy consensus and move forward with that plan.
> > >
> > > Assuming we do move forward with a release, are there any
> > > volunteers for release manager?
> > >
> > > ________________________________
> > >
> > >
> >
> > ________________________________
> >
> >
> > ________________________________
> >
> >
>
> ________________________________
>
>

________________________________

Reply via email to