ANN: Pacer 2.0.0.pre

[Darrick Wiebe]

pacer 2.0.0.pre is released!

Pacer is a graph traversal and stream processing library that makes it very easy to build sophisticated and very fast graph traversals.

This version is being pre-released because I would like feedback from the community on the new jar dependency management. Please try it out in your projects and let me know if you run into any problems with it. Barring any major problems, I plan to release 2.0.0 on November 21.

Pacer has been gradually evolving over the last couple of years and a major version bump is overdue. A lot more documentation has been written in recent months and xnlogic.com is sponsoring a new initiative to create the comprehensive documentation that many people have been asking me about.

## Changes

* switch from pre-built uberjar to jar dependencies via lock_jar.

## Changes from recent versions

* Added new count_section step

* Intersect multiple sets in the conditions for a single key in filters, and in Vertex#as

* Added Graph#read_transaction, needed for Neo4j 2.x but supported in Pacer by all graphs.

* Update to Blueprints 2.6

* Add unique_path step to cleanly eliminate cyclic traversals

* Add Graph#never_scan attribute. If set to true, routes without a concrete starting point or an index will raise Pacer::ClientError

* Return count of number of elements deleted when calling #delete!

* Many minor bugfixes and improvements

## Docs, source code, etc

https://github.com/pangloss/pacer

https://github.com/pangloss/pacer/wiki

## Accompanying this release:

* pacer-neo4j 2.3.0.pre (on Neo4j 1.9.7)

* pacer-neo4j2 2.1.5.pre (on Neo4j 2.1.5)

* pacer-orient 2.3.1.pre (on Orient 2.0-SNAPSHOT)

[Ilya Kardailsky]

Hi Darrick,

Great release once again, thank you.

I notice pacer-master is running Lockjar.lock in lib/pacer.rb, is there any other way to do this?

I'm currently using the (experimental) Bundler support in lock_jar to read the jarfiles from other gems, and locking again like this unexpectedly resets my Jarfile.lock to include only the current project's jars (and not the ones from other gems), not sure if this is the best way.

I'm currently working on pacer-titan to add support Titan 0.5.1, will push my changes and upload a new gem once I get this ironed out and get a few more tests to pass - had to make a few changes to support vertex labels. Their next release is looking at TP3 support, were you planning on keeping Pacer up to speed with all the new pipes? Happy to help where I can.

Cheers,

Ilya

[Darrick Wiebe]

Hi Ilya,

Thanks :)

Yes, I've realized that it's not quite right to call #lock in the library. I've been thinking about how to do this best but am a bit hesitant to use the bundler integration...

I was thinking of either adding a method to Pacer or monkey-patching LockJar itself (pending a PR there maybe?), something like #register_jarfile and then #combine_and_lock or something called as late as possible. I was thinking of making the combine_and_lock method idempotent and then adding it in to the graph constructor methods (ie. Pacer.tg, Pacer.neo4j, etc). That way users could register additional jars if needed, but then jar locking could still happen at the last possible moment.

Thoughts?

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/d/optout.

[Ilya Kardailsky]

There was some talk on lock_jar's git issues page about refactoring the bundler integration by allowing a Jarfile to specify that lock_jar needs to scan the gems for further Jarfiles on lock, sounds like it's a work in progress. The current bundler integration is working well for my development setup, we will try it for some tests in production environment soon.

I'm still quite new to building Java apps with all the dependency/classpath work, but my impression is it would be good to configure dependencies in one place via a Bundler-like Jarfile/Gemfile approach. It would be nice if this was done later in the graph constructor but, for the Titan example anyway, choosing a different storage backend requires different jar dependencies. I'm currently adding titan-core in the gem's Jarfile and titan-cassandra with titan-es in my application's Jarfile. I guess the graph constructor could also read the .properties file submitted to Titan and require the appropriate jars at that point.

Cheers,

Ilya