Pacer Benefits

[Dave]

Hi,

I have a Rails application on JRuby and wondered what the main benefits of using Pacer are versus just calling the Gremlin/Blueprints API directly?  Is the main differentiator that Pacer deviates a little from Gremlin and introduces some new traversal functionality or does it provide a much cleaner Ruby API layer, or both ---- or, something completely different :-)  ??     Our backend database is Titan. I'm currently manipulating data calling the Tinkerpop APIs directly. 

Thanks,

Dave

[Steven McCraw]

Hey Dave!  Sadly, I have no answers for you.  I am exactly in your shoes, using Titan and trying to figure out how to move forward, except I started with Pacer.  It seemed like a really great idea, because I love the idea of traversing a graph with the simple notation it provides (g.v(:name => 'mark').out_e(:friend).in_v(:type => 'person').  It never even occurred to me that pacer's functionality kind of makes a hard stop at traversal.  All of the documentation and examples show how to traverse a graph, but nothing really explains what kind of thing you get back from doing a traversal.  With a lot of sweat, I've figured out (I think) that what you actual get is some ilk of a Pacer::Core::Route, but I expected to get back a Vertex or something with behavior that you would expect a vertex to have, like the ability to alter the properties on the vertex.  I still haven't figured out how to do that without doing something like g.v(:number => 'foo').subgraph.blueprints_graph, which spits me into the java Blueprints hierarchy (com.tinkerpop.blueprints.impls.tg), and to be honest I still haven't figured out how I can do a search, get a handle to a specific vertex, modify one of the properties of that vertex, and commit that change.

That seems like pretty basic functionality, but either I'm being dense and am missing something in what little documentation I can find (I can't find much) or there's kind of a lot going on behind the scenes that will take a really long time to slog through in source code.

Can someone on this list help us understand what the status of this project is?  Is it worth my time trying to use it in a production project?  Are people supporting it, and is there good hidden documentation somewhere?  Who else is actually using it?  I love the idea, and the readme is beguiling, but I really need some help beyond "here's what you do to see the properties of a give vertex or edge".

Thanks!

Mark

[Darrick Wiebe]

Hey guys,

Pacer is definitely being used in production in multiple organizations and is being actively maintained. In my opinion it's by far the best way to work with graphs from Ruby or any other language.

One of the great advantages of it is that while it gives you really great syntax for doing pretty much whatever you need to do with a graph, you still have the option to use the blueprints APIs directly or even move code to pure Java when it comes time to optimize your app (though in my experience that's never been necessary).

There's plenty more to Pacer than just traversal. Your example code produces a route. if you want to get an actual vertex from it, you'd need to terminate the route with a method like #first which will give you one vertex, or #each or #bulk_job that will run through the elements the route produces.

I'd recommend looking at the test suite to see how the core functionality of Pacer works, though a guide would be useful, that'll have to suffice for now...  A couple of pointers though:

* elements will always be wrapped in either Pacer::Wrappers::VertexWrapper or EdgeWrapper

* basic core operations are all defined under lib/pacer/core

* more interesting operations are each defined separately under their own modules in the lib/pacer/filter, lib/pacer/transform and lib/pacer/side_effect paths. A lot of those have attr_accessor or settable attributes defined. Each of those is a possible option for the creation of that route step. So for instance with future_filter.rb, you see `attr_accessor :min, :max`. At the top you see that it defines the route chaining method `lookahead` which takes a block. Therefore you can use it like this: `graph.v.lookahead(min: 5, max: 7) { |v| v.out_e }`

Hope that helps, and I'm happy to help you out with specific questions.

Cheers,

Darrick

--
You received this message because you are subscribed to the Google Groups "pacer-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pacer-users...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[David Colebatch]

Hey guys,

I just wanted to follow up.  We (xnlogic) are heavily using pacer on client projects, and presenting a lot of details around pacer at GraphTO[1].

While there is a lack of API documentation on any web-site, we do currently have inline help built right into pacer when you're working in the REPL.  I recommend checking out some of our slides[2], specifically pacer in the REPL which is from slide 19[3] and also Darrick's gist[4] from the last meetup[5].

Pacer is an integral part of the xnlogic framework, and so as Darrick says, it will be supported for a long time to come.  We love contributions too BTW, and perhaps a documentation repo that we can host on github would be a great place to start?

We'd love to hear how you are using paceR…if it is something you can share with us, of course.

HTH. 

1: https://twitter.com/graphto

2: http://www.slideshare.net/DavidColebatch/presentations

3: http://www.slideshare.net/DavidColebatch/20121029-graph-tointro-to-pacer

4: https://gist.github.com/pangloss/4710452

5: http://www.meetup.com/GraphTO/events/92540182/

--

David Colebatch

w: http://relatedentities.com

t: @dcolebatch

e: d...@xnlogic.com

[Mark McCraw]

Hey David,

That is tremendously helpful, thanks!  I'm sort of feeling my way through things, and I do like pacer very much!  When I feel like I have a very good handle on how everything works, I'll try to capture it in written documentation and maybe that text can merge into the Readme if it makes sense to you.

Thanks so much for your responses.

Mark