In the unit test test-to-map-id in both vertex_test and edge_test, the id get converted from a number to a string by the to-map call.

edges-between is a method that takes in vertices and returns edges. Should probably be in vertex.clj.

I'd expect from a library with such a name to provide a way to shout "Eureka!" one way or another. According to the legend, Archimedes rushed home from a bath after discovering the way to measure volume of irregular objects. I therefore propose the function do something just
as awkward: just print "Eureka" to stdout, in all capital letters.

Needs to be added to travis-ci

It looks like Query.Compare has been deprecated in favour of com.tinkerpop.blueprints.Compare, along with a change to argument order in Query/has.

This could simplify the code some.
http://thornydev.blogspot.ru/2012/09/before-and-after-logic-in-clojuretest.html

Investigate why the tests passed even though graph.startTransaction no longer exists in Blueprints 2.3.0.

Make it possible to store clojure vectors as values of vertices.

As the Gremlin javadocs says about properties:

The key of a property is always a String and the value of a property is an arbitrary Java object. Each underlying graph engine will typically have constraints on what Java objects are allowed to be used as values.

And https://tinkerpop.apache.org/javadocs/current/core/org/apache/tinkerpop/gremlin/structure/VertexProperty.Cardinality.html indicates that a property may contain a single value, a list of values, or a set of values. Currently we call flatten which destroys any collection here

https://github.com/clojurewerkz/archimedes/blob/master/src/archimedes/edge.clj#L106

On the line above it uses in-vertex instead of out-vertex. It should be out-vertex since we want to find all edges for which direction is v1 -> v2, so v2 is the out-vertex for v1.

in alpha5, edge/connect! fails using TinkerGraph
topoged.data.blueprints> (e/connect! (first v) :dummy (second v))
IllegalArgumentException No matching method found: addEdge for class com.tinkerpop.blueprints.impls.tg.TinkerGraph
clojure.lang.Reflector.invokeMatchingMethod (Reflector.java:53)

but edge/connect-with-id! works

topoged.data.blueprints> (e/connect-with-id! "id" (first v) :dummy (second v))

<TinkerEdge e[id][18-dummy->19]>

It sucks having to rewrite tests. There should be a way to reuse tests from within archimedes in other projects, like Titanium.

https://github.com/zmaril/archimedes/blob/master/src/archimedes/vertex.clj#L59

http://www.tinkerpop.com/docs/javadocs/blueprints/2.3.0/com/tinkerpop/blueprints/util/ElementHelper.html#copyProperties(com.tinkerpop.blueprints.Element, com.tinkerpop.blueprints.Element)

https://groups.google.com/forum/#!topic/clojure-titanium/wPtGBGO39Tc

When an element has a boolean property, weird things happen. If it's true it returns true but if it is false it returns the default value. There should be a better way to check if an element has a property or not.

query ns should add has-not function, wrapping com.tinkerpop.blueprints.Query/hasNot

Add this in.

Due to complications with dynamic vars, it is very hard to get Titanium to use the latest version of Archimedes. Additionally, best practices dictate that it is more useful to have methods that take the database connection as an argument instead of dynamically reassigning the graph. Thus something like (add-vertex) would become (add-vertex graph). This isn't too hard to implement, mostly just boxing text around.

The main issue is making sure that transactions are implemented properly. My initial reaction is to provide a transaction function that takes in a graph and a function to execute.

Some pseudo code:

(defn transact! [graph f]
  (let [t (.newTransaction graph)]
    (try (let [results (f t)]
           (.commit t)
           results)
         (catch Exception e (.rollback t)))))
(transact! graph (fn [graph] (add-vertex graph)))
;= Vertex[1]     

I'd like to make it not hard to use laziness inside the transactions. Right now, with something like the above, a map in the provided function could potentially execute after the transactions has been committed. That's the main blocking point for me right now, making the transactions work with lazy sequences properly.

http://en.wikipedia.org/wiki/Graph_operations

Specifically, graph operations like merging vertices, splitting vertices and edge contraction.

Refactor edge/edges-between to just use vertex queries. Shouldn't be all that hard and will make development easier.