Frontenac.Blueprints Namespace

Features provides a listing of the features/qualities/quirks associated with any Graph implementation. This feature listing can be used to dynamically adjust code to the features of the graph implementation. For example, this feature listing is used extensively throughout the Blueprints TestSuite to validate behavior of the implementation.

A CloseableIterable is required where it is necessary to deallocate resources from an IEnumerable.

An Edge links two vertices. Along with its key/value properties, an edge has both a directionality and a label. The directionality determines which vertex is the tail vertex (out vertex) and which vertex is the head vertex (in vertex). The edge label determines the type of relationship that exists between the two vertices. Diagrammatically, outVertex ---label---> inVertex.

An Element is the base class for both vertices and edges. An element has an identifier that must be unique to its inheriting classes (vertex or edges). An element can maintain a collection of key/value properties. Keys are always Strings and values can be any object. Particular implementations can reduce the space of objects that can be used as values. Typically, objects are C# primitives (e.g. string, long, int, boolean, etc.)

A Graph is a container object for a collection of vertices and a collection edges.

An IIndexableGraph is a graph that supports the manual indexing of its elements. An index is typically some sort of tree structure that allows for the fast lookup of elements by key/value pairs. Indices have an Index object associated with them and allow the user to specify the putting and getting of elements into the index.

A KeyIndexableGraph is a graph that supports basic index functionality around the key/value pairs of the elements of the graph. By creating key indices for a particular property key, that key is indexed on all the elements of the graph. This has ramifications for quick lookups on methods like getVertices(string, object) and getEdges(string, object).

ThreadedTransactionalGraph provides more fine grained control over the transactional context. While TransactionalGraph binds each transaction to the executing thread, ThreadedTransactionalGraph's newTransaction returns a TransactionalGraph that represents its own transactional context independent of the executing thread. Hence, one can have multiple threads operating against a single transaction represented by the returned TransactionalGraph object. This is useful for parallelizing graph algorithms. Note, that one needs to call TransactionalGraph.Commit() or TransactionalGraph.Rollback() to close the transactions returned

A transactional graph supports the notion of transactions. A transaction scopes a logically coherent operation composed of multiple read and write operations that either occurs at once or not at all. The exact notion of a transaction and its isolational guarantees depend on the implementing graph database. A transaction scopes a coherent and complete operations. Any element references created during a transaction should not be accessed outside its scope (i.e. after the transaction is committed or rolled back). Accessing such references outside the transactional context they were created in may lead to exceptions. If such access is necessary, the transactional context should be extended. By default, the first operation on a TransactionalGraph will start a transaction automatically.

A vertex maintains pointers to both a set of incoming and outgoing edges. The outgoing edges are those edges for which the vertex is the tail. The incoming edges are those edges for which the vertex is the head. Diagrammatically, ---inEdges---> vertex ---outEdges--->.

A VertexQuery object defines a collection of filters and modifiers that are used to intelligently select edges from a vertex.