Any plans on making the return methods generic so we can specialize them?
For instance, instead of
public interface Graph {
public Iterator<Vertex> vertices(final Object... vertexIds);
}
to have
public interface Graph<V extends Vertex> {
public Iterator<V> vertices(final Object... vertexIds);
}
That way, orientdb-gremlin can expose custom operations and even enforce
types for things like Element.id() and many other creative thinking =D
On Tue, Feb 2, 2016 at 3:52 AM, Marko Rodriguez <okramma...@gmail.com>
wrote:
> Hi,
>
> I think 3.2.0 can include breaking changes if need be. However, I believe
> all the things that I want to do will be have @Deprecated backwards
> compatible solutions.
>
> Marko.
>
> http://markorodriguez.com
>
> On Feb 1, 2016, at 4:25 AM, Stephen Mallette <spmalle...@gmail.com> wrote:
>
> > Is 3.2.0 going to be considered a "breaking" version in the sense that we
> > need to alter some APIs? or will it be possible to do 3.2.0 without that?
> > I'm in favor of a breaking version for 3.2.0 so that we can try to clean
> up
> > some old code especially if we have other changes driving that.
> >
> > On Sat, Jan 30, 2016 at 7:55 PM, Marko Rodriguez <okramma...@gmail.com>
> > wrote:
> >
> >> Hello Pieter,
> >>
> >>> A tad selfish I know,
> >>> but https://issues.apache.org/jira/browse/TINKERPOP-968 is what I am
> >>> waiting for.
> >>
> >> The things I listed are what I care about and what I plan to work on. If
> >> you have things you care about, you can work on those. If you are
> unsure of
> >> a development strategy, perhaps you can get others excited about your
> idea
> >> with a [DISCUSS], work through pros/cons, get some buy in, etc. From
> there,
> >> develop the idea, test it, document it, and ultimately provide a PR to
> get
> >> it merged into a release line.
> >>
> >> http://tinkerpop.apache.org/docs/3.1.1-SNAPSHOT/dev/developer/
> >>
> >> SIDENOTE: A few people emailed me personally saying comments to the
> >> effect: "Please deliver X, Y, Z feature." Note, if you want something
> done,
> >> do it. If you don't know how to do it, learn it. If you don't know how
> to
> >> learn it, ask and we can point you in the right direction. If you don't
> >> know how to ask -- I know you are lying cause you asked me to deliver
> X, Y,
> >> Z. Gotcha!
> >>
> >> Take care,
> >> Marko.
> >>
> >> http://markorodriguez.com
> >>
> >>>
> >>> Cheers
> >>> Pieter
> >>>
> >>> On 30/01/2016 19:09, Marko Rodriguez wrote:
> >>>> Hello,
> >>>>
> >>>> With TinkerPop 3.1.1 about to be put up for VOTE, we can start to turn
> >> our attentions towards 3.1.2 and 3.2.0.
> >>>>
> >>>> I was thinking it would be good to have a planning session to organize
> >> JIRA and discuss order of operations. However, JIRA planning sessions
> are a
> >> bit boring as they are too "nitty gritty," so perhaps we can use this
> >> thread to discuss what we (as individuals) would like to accomplish for
> >> 3.1.2 and 3.2.0 in general. This way, we have more summaries of
> everyone's
> >> desires and then the specifics can be shakin' out in JIRA. As such, here
> >> are my desires:
> >>>>
> >>>> TinkerPop 3.1.2
> >>>> * Test a new shuffle optimization idea in SparkGraphComputer and
> >> if its efficient, use it.
> >>>> * Benchmark GiraphGraphComputer at scale and optimize it where
> >> need be.
> >>>>
> >>>> TinkerPop 3.2.0
> >>>> * Gremlin DSLs -- e.g.
> >>
> social.people().aged(36).who().know().person("daniel").who().worksFor().company("cisco")
> >>>> * TraversalSource API redesign. g =
> >> graph.traversal().withComputer(…).withStrategy(…).withBulk(…). The
> current
> >> TraversalSourceBuilder model is horrible.
> >>>> * OLTP/OLAP-mixed traversal -- e.g.
> >>
> OLAP[g.V().out()]OLTP[limit(10)]OLAP[out().values("name").order()]OLTP[sample(1)]
> >>>> * GraphComputer API additions for intelligent data access -- e.g.
> >> g.V().count() does not need to grab all the edges of the graph!
> >>>> * Bulking beyond Long -- support BigInteger, Complex numbers,
> >> Doubles, etc.
> >>>> * Redesign TraverserRequirements -- this is a rats nest that
> >> didn't really work out as planned and its inefficient. I think I can
> make
> >> this a lot more simple.
> >>>> * ServerGraph/ServerStep/ServerStrategy -- like OLAP, but for
> >> GremlinServer -- e.g. [GraphStep, VertexStep, ServerStep] (collaborate
> with
> >> GremlinServer people on this).
> >>>> * Scope.local & Scope.global rethinking -- count(local),
> >> dedup(local) … too many -- this is not manageable! What about
> >> g.V().groupCount().inside(order().limit(10)) instead of
> >> g.V().groupCount().order(local).limit(local,10).
> >>>> * Clean up HadoopGraph configurations -- Why do we have
> >> gremlin.spark.graphInputRDD and gremlin.hadoop.graphInputFormat. We
> should
> >> just have one configuration: gremlin.hadoop.graphInputClass.
> >>>> * Publish a tutorial on the Gremlin VM and compiling other
> >> languages to it. I would really like to have the gremlin-examples/
> package
> >> that Jason/Stephen were talking about.
> >>>> * Optimize Gryo serialization and SparkGraphComputer's
> >> GryoSerializer.
> >>>>
> >>>> Those are the big ticket items that I would like to get handle for the
> >> next versions of TinkerPop.
> >>>>
> >>>> What are your thoughts on these and what are your thoughts on what you
> >> plan to accomplish in this next push?
> >>>>
> >>>> Take care,
> >>>> Marko.
> >>>>
> >>>> http://markorodriguez.com
> >>>>
> >>>>
> >>>
> >>
> >>
>
>
