PGX 2.7.0
Documentation

What is New in PGX 2.7


PGX API

PGX 2.7.0 extends the PGX API with support for scalar collections. Scalar collections are server-side data structures that can hold primitive data types like Integer, Long, Float and Double. Users can create and handle scalar collections using the oracle.pgx.api.PgxSession API; e.g., session.createSet(INTEGER) will return a reference to a ScalarSet<INTEGER>, which represents a set of integers. Scalar collections are subclasses of the new oracle.pgx.api.ScalarCollection class and are session-bound, i.e., they do not refer to a specific graph, but to a session. Refer to the new PGX data types tutorial for more information.

New analytics algorithms

PGX.SM, the single machine, shared memory execution engine included in PGX adds two algorithms to the list of supported builtins: Topological Sort and Topological Schedule.

PGX.D, the scale-out, distributed execution engine included in PGX extends its builtin analytics algorithm support with thirteen new algorithms from the supported algorithms list: Weighted Pagerank, Personalized Weighted Pagerank, Vertex Betweenness Centrality, Closeness Centrality Unit Length, Hits, Out Degree Centrality, In-Degree Centrality, Degree Centrality, Conductance, Partition Modularity, Partition Conductance, Diameter, and Periphery.

Extended PGQL 1.1 support

PGX 2.7.0 further extends support for PGQL 1.1.

Support for EXISTS and NOT EXISTS subqueries

Users can now express existential subqueries. For example:

SELECT a.name, b.name MATCH (a)-[:friendOf]->(b) WHERE
  EXISTS (SELECT * MATCH (a)-[:friendOf]->(c)-[:friendOf]->(b))

Support for subqueries inside the PATH clause

Users can now express a sub-query in the WHERE clause of the PATH definition. For illustration, the following example defines a path ending in a vertex which is not the oldest in the graph:

PATH p AS (a) -> (b) WHERE EXISTS (SELECT * MATCH (x) WHERE x.age > b.age) SELECT ...

One limitation of the current implementation is that only simple constraints (constraints accessing at most one of the pattern variables) are allowed under the WHERE clause. Queries like:

PATH p AS (a) -> (b) WHERE EXISTS (SELECT * MATCH (a) -> (c) -> (b)) SELECT ...

are not yet supported.

Support for creating vertex/edge sets out of a PGQL result set

Users can now create vertex or edge sets from of a given PGQL result set. In the following example, the PGQL query selects all the vertices with values for the property age greater than 24 and then the getVertices() creates a vertex set containing such vertices.

resultSet = g.queryPgql("SELECT x MATCH (x) WHERE x.age > 24")
vertexSet = g.getVertices(new ResultSetVertexFilter(resultSet, "x"))

This operation is executed on the PGX server when running in client-server mode and removes the need to fetch the result set to the client side in order to create a collection. This improvement brings performance benefits for result sets of any size and enables handling very large result sets that may be troublesome to handle on a client machine.

Ability to share graphs by name

PGX now supports graph sharing by name, allowing to mark graphs as shared and retrieve them from any session the graph name. Users can mark graphs as shared with other sessions by calling graph.publish() and other sessions can get a reference to the published graphs via session.getGraph("<name>"). Users can see which graphs have been published by calling session.getGraphs(). The owner of a shared graph can modify its name by calling graph.rename("<name>").

Besides graphs, individual properties of a graph can be shared, too, by calling property.publish().

One implication of this feature is that all graph names must now be globally unique across sessions.

More information on graph sharing can be found in the "Publish a graph" tutorial.

Changelog

All the changes and fixes shipping with PGX 2.7 are listed in the changelog.