Announcing pacer-rexster 1.0.0

[Darrick Wiebe]

Hi all,

I just threw together a Rexster adapter for Pacer. 

Here's a little gist of it in action: https://gist.github.com/1168902

Cheers!

Darrick

[Steven McCraw]

Hi Darrick,

This looks really neat!  I downloaded it this morning to play around with it and see if I could get it to work, but I get this:

NameError: uninitialized constant Java::ComTinkerpopBlueprintsPgmImplsRexster::RexsterVertex::ElementMixin

  const_missing at org/jruby/RubyModule.java:2694

  RexsterVertex at /Users/mccraw/Documents/com.sas.deployment.datastore/lib/ruby/pacer-rexster/vertex.rb:8

          Pacer at /Users/mccraw/Documents/com.sas.deployment.datastore/lib/ruby/pacer-rexster/vertex.rb:6

         (root) at /Users/mccraw/Documents/com.sas.deployment.datastore/lib/ruby/pacer-rexster/vertex.rb:3

        require at org/jruby/RubyKernel.java:1028

        require at jar:file:/Users/mccraw/Documents/com.sas.deployment.datastore/lib/java/jruby-complete.jar!/META-INF/jruby.home/lib/ruby/shared/rubygems/custom_require.rb:36

         (root) at /Users/mccraw/Documents/com.sas.deployment.datastore/lib/ruby/pacer-rexster.rb:1

        require at org/jruby/RubyKernel.java:1028

        require at jar:file:/Users/mccraw/Documents/com.sas.deployment.datastore/lib/java/jruby-complete.jar!/META-INF/jruby.home/lib/ruby/shared/rubygems/custom_require.rb:36

         (root) at /Users/mccraw/Documents/com.sas.deployment.datastore/lib/ruby/pacer-rexster.rb:9

        require at org/jruby/RubyKernel.java:1028

         (root) at /Users/mccraw/Documents/com.sas.deployment.datastore/lib/ruby/titan.rb:1

         (root) at lib/ruby/main.rb:149

The code being executed looks like this:

  class RexsterVertex

    include Pacer::Core::Graph::VerticesRoute

    include ElementMixin

    include VertexMixin

  end

I found a refactoring commit notice that mentioned moving the '...Mixin' pieces into wrapper classes:

https://github.com/pangloss/pacer/commit/2d7a224f0423b04a58ec4c2838164da9ffcb80fc

So the error message makes good sense.  But I can't include the contents of a class in a class, and since the code is no longer captured in modules, I'm a little stuck I guess.  Apparently no one is using this, since it's been broken for almost a year, but I can't understand why.  It seems like such a great idea for tacking a graph datastore onto an existing rails application, for instance, which still uses a relational datastore as well (that's how I want to use it, anyway).  Any suggestions to make this work?

Also, one quick question:  Does this go through rexster's REST API, or does it use the binary protocol (which I assume is much more efficient)?

Thanks!

Mark

[Darrick Wiebe]

Hi Mark,

Yeah, I haven't looked at this project in quite a while, since my focus has been largely on using pacer-neo4j in embedded mode. I'll take a look at the pacer-rexster project though, if it's not too much work it would be good to bring it up to date.

As for which protocol is being used, that old version probably used REST since I think that was all that was available then, but I'm just using the standard Blueprints Rexster client under the hood, so once it's brought up to date I'd expect it use the best one available by default.

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.
 
 

[Steven McCraw]

That's really cool, thanks for replying so quickly.  The other thing I found that kind of approximates this is this thing:

https://github.com/lann/rexpro-ruby

which does use the binary protocol.  It seems to be a ruby wrapper around rexpro, which is the binary protocol.  It looks like you specify your queries/etc using gremlin, and then it translates what comes back into ruby collections for you.  That seems ok I guess, but not as cool as simply swapping a few lines in my pacer config and having everything work the same way!

I've also been struggling with how to weigh the pros/cons of embedded vs. standalone.  Standalone works great for an isolated client that I've written (where each client instance needs its own datastore), but it seems like having a standalone thing that multiple consumers can connect to makes the most sense for the in-house server application I'm working on, so that my application can live in a clustered HA environment without having to worry about what that means for the datastore.  Any thoughts on that?

Thanks!

Mark

[Darrick Wiebe]

It really depends on your needs and the complexity of your business model, I think. Using Rexster is good if you want to treat the graph the way you'd treat something like a MySQL server, ie. as an endpoint that you can hit with arbitrary queries and which has no information about your domain or business logic. In that model, you would have one or more trusted clients that effectively have admin access to the graph datastore.

An alternative is to have an API server that embeds the graph, and which has knowledge of your domain. That lets it serve queries in the language of your domain, enforce data integrity and security and a bunch of other benefits besides. That is the approach that we've taken at xnlogic with our graph application framework -- which is built on top of Pacer -- and which has been very successful for building LightMesh, among other projects. If you're at all interested, email me directly at d...@xnlogic.com. I'd love to show you a bit more of what we've built over the last couple of years!

Regardless, I'm always happy to hear from Pacer users and am happy to help you out where I can!

Cheers,

Darrick