OrientDB Distributed Graph Database http://orientdb.com OrientDB is a Multi-Model NoSQL Database with a true Graph engine Mon, 26 Sep 2016 21:49:34 +0000 en-US hourly 1 Released OrientDB v2.2.10 http://orientdb.com/released-orientdb-v2-2-10/ http://orientdb.com/released-orientdb-v2-2-10/#comments Thu, 15 Sep 2016 14:26:21 +0000 http://orientdb.com/?p=16043 London, September 15, 2016 The OrientDB Team has just released OrientDB v2.2.10, resolving 12 issues from v2.2.9. If you are using 2.2.x series, please […]

The post Released OrientDB v2.2.10 appeared first on OrientDB Distributed Graph Database.

]]>
London, September 15, 2016

The OrientDB Team has just released OrientDB v2.2.10, resolving 12 issues from v2.2.9. If you are using 2.2.x series, please upgrade your production environments to v2.2.10. For more information, take a look at the Change Log.

Download OrientDB v2.2.10 now: http://orientdb.com/download

If you are currently using a previous version of OrientDB, we recommend you upgrade using the link above. However, if you would like to download previous versions of OrientDB Community Edition, you may do so here: http://orientdb.com/download-previous/

A big thank you goes out to the OrientDB team and all the contributors who worked hard on this release, providing pull requests, tests, issues and comments.

Best regards,

Luigi Dell’Aquila
Director of Consulting
OrientDB LTD

The post Released OrientDB v2.2.10 appeared first on OrientDB Distributed Graph Database.

]]>
http://orientdb.com/released-orientdb-v2-2-10/feed/ 0
Released OrientDB v2.2.9 http://orientdb.com/released-orientdb-v2-2-9/ http://orientdb.com/released-orientdb-v2-2-9/#comments Thu, 08 Sep 2016 14:44:29 +0000 http://orientdb.com/?p=16029 London, September 8, 2016 The OrientDB Team has just released OrientDB v2.2.9, resolving 14 issues from v2.2.8. If you are using 2.2.x series, please […]

The post Released OrientDB v2.2.9 appeared first on OrientDB Distributed Graph Database.

]]>
London, September 8, 2016

The OrientDB Team has just released OrientDB v2.2.9, resolving 14 issues from v2.2.8. If you are using 2.2.x series, please upgrade your production environments to v2.2.9. For more information, take a look at the Change Log.

Download OrientDB v2.2.9 now: http://orientdb.com/download

If you are currently using a previous version of OrientDB, we recommend you upgrade using the link above. However, if you would like to download previous versions of OrientDB Community Edition, you may do so here: http://orientdb.com/download-previous/

A big thank you goes out to the OrientDB team and all the contributors who worked hard on this release, providing pull requests, tests, issues and comments.

Best regards,

Luigi Dell’Aquila
Director of Consulting
OrientDB LTD

The post Released OrientDB v2.2.9 appeared first on OrientDB Distributed Graph Database.

]]>
http://orientdb.com/released-orientdb-v2-2-9/feed/ 0
Released OrientDB v2.2.8 http://orientdb.com/released-orientdb-2-2-8/ http://orientdb.com/released-orientdb-2-2-8/#comments Tue, 23 Aug 2016 15:51:20 +0000 http://orientdb.com/?p=15800 London, August 23, 2016 The OrientDB Team has just released OrientDB v2.2.8, resolving 12 issues from v2.2.7. If you are using 2.2.x series, please […]

The post Released OrientDB v2.2.8 appeared first on OrientDB Distributed Graph Database.

]]>
London, August 23, 2016

The OrientDB Team has just released OrientDB v2.2.8, resolving 12 issues from v2.2.7. If you are using 2.2.x series, please upgrade your production environments to v2.2.8. For more information, take a look at the Change Log.

Download OrientDB v2.2.8 now: http://orientdb.com/download

If you are currently using a previous version of OrientDB, we recommend you upgrade using the link above. However, if you would like to download previous versions of OrientDB Community Edition, you may do so here: http://orientdb.com/download-previous/

A big thank you goes out to the OrientDB team and all the contributors who worked hard on this release, providing pull requests, tests, issues and comments.

Best regards,

Luigi Dell’Aquila
Director of Consulting
OrientDB LTD

The post Released OrientDB v2.2.8 appeared first on OrientDB Distributed Graph Database.

]]>
http://orientdb.com/released-orientdb-2-2-8/feed/ 0
Released OrientDB v2.2.7 http://orientdb.com/released-orientdb-2-2-7/ http://orientdb.com/released-orientdb-2-2-7/#comments Thu, 11 Aug 2016 17:09:42 +0000 http://orientdb.com/?p=15753 London, August 11, 2016 The OrientDB Team has just released OrientDB v2.2.7, resolving 17 issues from v2.2.6. If you are using 2.2.x series, please […]

The post Released OrientDB v2.2.7 appeared first on OrientDB Distributed Graph Database.

]]>
London, August 11, 2016

The OrientDB Team has just released OrientDB v2.2.7, resolving 17 issues from v2.2.6. If you are using 2.2.x series, please upgrade your production environments to v2.2.7. For more information, take a look at the Change Log.

Download OrientDB v2.2.7 now: http://orientdb.com/download

If you are currently using a previous version of OrientDB, we recommend you upgrade using the link above. However, if you would like to download previous versions of OrientDB Community Edition, you may do so here: http://orientdb.com/download-previous/

A big thank you goes out to the OrientDB team and all the contributors who worked hard on this release, providing pull requests, tests, issues and comments.

Best regards,

Luigi Dell’Aquila
Director of Consulting
OrientDB LTD

The post Released OrientDB v2.2.7 appeared first on OrientDB Distributed Graph Database.

]]>
http://orientdb.com/released-orientdb-2-2-7/feed/ 0
Released OrientDB v2.2.6 http://orientdb.com/released-orientdb-2-2-6/ http://orientdb.com/released-orientdb-2-2-6/#comments Thu, 28 Jul 2016 08:28:07 +0000 http://orientdb.com/?p=15666 London, July 28, 2016 The OrientDB Team has just released OrientDB v2.2.6, resolving 11 issues from v2.2.5. If you are using 2.2.x series, please […]

The post Released OrientDB v2.2.6 appeared first on OrientDB Distributed Graph Database.

]]>
London, July 28, 2016

The OrientDB Team has just released OrientDB v2.2.6, resolving 11 issues from v2.2.5. If you are using 2.2.x series, please upgrade your production environments to v2.2.6. For more information, take a look at the Change Log.

Download OrientDB v2.2.6 now: http://orientdb.com/download

If you are currently using a previous version of OrientDB, we recommend you upgrade using the link above. However, if you would like to download previous versions of OrientDB Community Edition, you may do so here: http://orientdb.com/download-previous/

A big thank you goes out to the OrientDB team and all the contributors who worked hard on this release, providing pull requests, tests, issues and comments.

Best regards,

Luigi Dell’Aquila
Director of Consulting
OrientDB LTD

The post Released OrientDB v2.2.6 appeared first on OrientDB Distributed Graph Database.

]]>
http://orientdb.com/released-orientdb-2-2-6/feed/ 0
Spatial Module in OrientDB 2.2 http://orientdb.com/spatial-module-orientdb-2-2/ http://orientdb.com/spatial-module-orientdb-2-2/#comments Mon, 25 Jul 2016 14:28:21 +0000 http://orientdb.com/?p=15637 London, July 25, 2016 In versions prior to 2.2, OrientDB had minimal support for storing and retrieving GeoSpatial data. The support was limited to […]

The post Spatial Module in OrientDB 2.2 appeared first on OrientDB Distributed Graph Database.

]]>
London, July 25, 2016

In versions prior to 2.2, OrientDB had minimal support for storing and retrieving GeoSpatial data. The support was limited to a pair of coordinates (latitude, longitude) stored as double in an OrientDB class, with the possibility to create a spatial index against those 2 coordinates in order to speed up a geo spatial query. So the support was limited to Point.
In OrientDB v.2.2 we created a brand new Spatial Module with support for different types of Geometry objects stored as embedded objects in a user defined class

  • Point (OPoint)
  • Line (OLine)
  • Polygon (OPolygon)
  • MultiPoint (OMultiPoint)
  • MultiLine (OMultiline)
  • MultiPolygon (OMultiPlygon)
  • Geometry Collections

Along with those data types, the module extends OrientDB SQL with a subset of SQL-MM functions in order to support spatial data.The module only supports EPSG:4326 as Spatial Reference System. This blog post is an introduction to the OrientDB spatial Module, with some examples of its new capabilities. You can find the installation guide here.

Let’s start by loading some data into OrientDB. The dataset is about points of interest in Italy taken from here. Since the format is ShapeFile we used QGis to export the dataset in CSV format (geometry format in WKT) and import the CSV into OrientDB with the ETL in the class Points and the type geometry field is OPoint.

image08

Since the WKT field is in string format we have to create the geometry property in the Points class

create property Points.location EMBEDDED OPoint

 
And update it in order to insert the geometry field by using the Function ST_GeomFromText.

update Points set location = ST_GeomFromText(WKT)

 
In this way, we store the position in the field location stored as an Embedded object with an OPoint class and field coordinates. If we want to insert another point of interest we can use an SQL statement in the following way:

INSERT INTO Points SET name = “Some Name”, location = {"@class": "OPoint","coordinates" : [lon,lat]}

 
The order of lon/lat here in order to be GeoJSON compliant.

Alternetively, we may use the function to create the Point object from the WKT format:

INSERT INTO Points SET name = “Some Name”, location = St_GeomFromText("POINT (lon lat)")

 
Now let’s suppose that we are in the middle of Rome near Santa Maria in Trastevere, thirsty, and looking for something to drink. We could use the function ST_Distance_Sphere to find points that are near us within a max distance of, let’s say, 200 meters.

select *,ST_Distance_Sphere(location,ST_GeomFromText('POINT(12.4696635 41.8894657)')) as distance from Points where ST_Distance_Sphere(location,ST_GeomFromText('POINT(12.4696635 41.8894657)')) < 200 order by distance

 
image07

We can see that at ~113 meters distance we have a drinking water fountain. By using the location field in the result set, we can easily use the Google Maps API to create a map from that data.

image04

Now we want to know the same information but faster than before. Just create a spatial index on the location property:

create index Points.location on Points(location) SPATIAL ENGINE LUCENE

 
And execute the query again.

image05

Let’s complicate things a little bit. We said the new spatial module is able to handle different type of Geometry objects. With the same procedure as before (ShapeFile + QGis + CSV + ETL) we import the dataset of states and provinces boundaries of countries into OrientDB.
In this case the target class is ‘Provinces’ and the type geometry field is OMultipolygon, created with SQL

create property Provinces.geometry EMBEDDED OMultipolygon

 
Then we inspect some provinces of Italy just to check the imported data.

Once we have the provinces of Italy, we can use a spatial function to execute a nice query and extract interesting information.

For example we could use the ST_Contains function if we want know which is the Province of Calcata, a tiny little town near Rome.

select iso_3166_2,gn_name,region,geonunit from Provinces where ST_Contains(geometry, ST_GeomFromText('POINT(12.42617 42.21952)')) = true

 
image06

Or we could use the ST_Intersects function to get all the provinces that the Tiber river crosses. For this query, we extracted the WKT geometry data of the Tiber (MultiLineString) from here.

select iso_3166_2,gn_name,region,geonunit from Provinces where ST_Intersects(geometry, ST_GeomFromText(<MultiLineString>) = true order by region

 
where <MultiLineString> is the WKT notation of the Tiber

At this point, it is also possible to create a map with the provincial boundaries.

There are other implemented functions bundled with the module. You can find the full documentation here. The Spatial Module is a new feature in OrientDB v.2.2, if you want to see it improved with new functionalities, please drop us a line using OrientDB’s issue tracker.

Hoping this comes in handy,

Enrico Risa
OrientDB LTD

The post Spatial Module in OrientDB 2.2 appeared first on OrientDB Distributed Graph Database.

]]>
http://orientdb.com/spatial-module-orientdb-2-2/feed/ 0
Released OrientDB v2.2.5 http://orientdb.com/released-orientdb-2-2-5/ http://orientdb.com/released-orientdb-2-2-5/#comments Wed, 20 Jul 2016 15:47:44 +0000 http://orientdb.com/?p=15617 London, July 20, 2016 The OrientDB Team has just released OrientDB v2.2.5, resolving 12 issues from v2.2.4. If you are using 2.2.x series, please upgrade […]

The post Released OrientDB v2.2.5 appeared first on OrientDB Distributed Graph Database.

]]>
London, July 20, 2016

The OrientDB Team has just released OrientDB v2.2.5, resolving 12 issues from v2.2.4. If you are using 2.2.x series, please upgrade your production environments to v2.2.5. For more information, take a look at the Change Log.

Download OrientDB v2.2.5 now: http://orientdb.com/download

If you are currently using a previous version of OrientDB, we recommend you upgrade using the link above. However, if you would like to download previous versions of OrientDB Community Edition, you may do so here: http://orientdb.com/download-previous/

A big thank you goes out to the OrientDB team and all the contributors who worked hard on this release, providing pull requests, tests, issues and comments.

Best regards,

Luigi Dell’Aquila
Director of Consulting
OrientDB LTD

The post Released OrientDB v2.2.5 appeared first on OrientDB Distributed Graph Database.

]]>
http://orientdb.com/released-orientdb-2-2-5/feed/ 0
Released OrientDB 2.2.4 http://orientdb.com/released-orientdb-2-2-4/ http://orientdb.com/released-orientdb-2-2-4/#comments Sat, 09 Jul 2016 09:30:00 +0000 http://orientdb.com/?p=15444 London, July 8, 2016 The OrientDB Team has just released OrientDB v2.2.4, resolving 26 issues from v2.2.3. If you are using 2.2.x series, please upgrade […]

The post Released OrientDB 2.2.4 appeared first on OrientDB Distributed Graph Database.

]]>
London, July 8, 2016

The OrientDB Team has just released OrientDB v2.2.4, resolving 26 issues from v2.2.3. If you are using 2.2.x series, please upgrade your production environments to v2.2.4. For more information, take a look at the Change Log.

Download OrientDB v2.2.4 now: http://orientdb.com/download

If you are currently using a previous version of OrientDB, we recommend you upgrade using the link above. However, if you would like to download previous versions of OrientDB Community Edition, you may do so here: http://orientdb.com/download-previous/

A big thank you goes out to the OrientDB team and all the contributors who worked hard on this release, providing pull requests, tests, issues and comments.

Best regards,

Luigi Dell’Aquila
Director of Consulting
OrientDB LTD

The post Released OrientDB 2.2.4 appeared first on OrientDB Distributed Graph Database.

]]>
http://orientdb.com/released-orientdb-2-2-4/feed/ 0
Using the Spark Connector for OrientDB http://orientdb.com/spark-orientdb/ http://orientdb.com/spark-orientdb/#comments Fri, 08 Jul 2016 12:50:42 +0000 http://orientdb.com/?p=15383 London, July 8, 2016 By Andrea Iacono The Spark connector for OrientDB has been provided by Metreta and hosted on github at https://github.com/metreta/spark-orientdb-connector, letting Spark […]

The post Using the Spark Connector for OrientDB appeared first on OrientDB Distributed Graph Database.

]]>
London, July 8, 2016
By Andrea Iacono

The Spark connector for OrientDB has been provided by Metreta and hosted on github at https://github.com/metreta/spark-orientdb-connector, letting Spark and OrientDB interoperate in two ways: accessing OrientDB data from Spark and writing Spark data to OrientDB. The connector is also aware of the difference between an OrientDB document database and an OrientDB graph database:

  • Using OrientDB as a documents database: The OrientDB documents can be read from/written to Spark RDDs.
  • Using OrientDB as a graph database: The vertices and edges can be read from/written to Spark GraphX graphs.

To compile the connector, clone the master branch and update its build.sbt file with the Scala version and the Spark version you’re using. You may subsequently launch the package command on sbt:

sbt package

 

Upon performing these steps, you should find a jar file containing the compiled connector in your target directory. Be sure to have created the test database as well (as shown in the connector’s page).

The first step for creating our sample project is to create a build.sbt, where we have to define the library dependencies:

libraryDependencies ++= Seq(
 "com.orientechnologies" % "orientdb-core" % "2.2.3",
 "com.orientechnologies" % "orientdb-client" % "2.2.3",
 "com.orientechnologies" % "orientdb-graphdb" % "2.2.3",
 "com.orientechnologies" % "orientdb-distributed" % "2.2.3",
 "org.apache.spark" % "spark-core_2.11" % "1.6.1",
 "org.apache.spark" % "spark-graphx_2.11" % "1.6.1",
 "org.scala-lang" % "scala-compiler" % "2.11.4",
 "org.scala-lang" % "scala-library" % "2.11.4",
 "org.scala-lang" % "scala-reflect" % "2.11.4",
 "jline" % "jline" % "2.12",
 "com.tinkerpop.blueprints" % "blueprints-core" % "2.6.0",
 "com.fasterxml.jackson.core" % "jackson-databind" % "2.7.4",
 "com.fasterxml.jackson.module" % "jackson-module-scala_2.11" % "2.7.4"
)

 

We must then configure Spark to attach to OrientDB, which we can do by defining the SparkConf in the following way:

  val conf = new SparkConf()
    .setMaster("local[*]")
    .setAppName("ConnectorSample")
    .set("spark.orientdb.clustermode", "remote")
    .set("spark.orientdb.connection.nodes", "127.0.0.1")
    .set("spark.orientdb.protocol", "remote")
    .set("spark.orientdb.dbname", "test")
    .set("spark.orientdb.port", "2424")
    .set("spark.orientdb.user", "admin")
    .set("spark.orientdb.password", "admin")

 

We can now share data between Spark and OrientDB.

Orient Documents to/from Spark RDDs
Let’s start reading some OrientDB documents as a Spark RDD:

var peopleRdd: RDD[OrientDocument] = sc.orientQuery("Person")

 

With the orientQuery() method, we can read the documents of a class from OrientDB and may have them as a Spark RDD, on which we can do the usual manipulations. We can then save them back to OrientDB:

peopleRdd
 .filter(person => person.getString("name") == "John")
 .map(person => new Person("Foo", "Bar"))
 .saveToOrient("Person")

 

Like in this example where, after a bit of manipulation, we use the saveToOrient() method to save all the elements of the RDD as OrientDB documents, we can check both querying OrientDB via Studio or querying from the code:

sc.orientQuery("Person").foreach(p => println(s"Person: ${p.getString("surname")}, ${p.getString("name")}"))

 

We can also update the OrientDB documents using the upsertToOrient() method, as shown in this example where we update a document’s property via the RDD and save them back to OrientDB:

peopleRdd
 .filter(person => !person.getString("surname").startsWith("New"))
 .map(person => new Person(person.getString("name"), "New " + person.getString("surname")))
 .upsertToOrient("Person")

 

Orient Graphs to/from Spark GraphX
When we deal with graphs, RDDs are not enough and so we must move to Spark’s API for graph computing: GraphX.

To access OrientDB vertices and edges, we must use the orientGraph() method as shown in this example:

val peopleGraph: Graph[OrientDocument, OrientDocument] = sc.orientGraph()

 

Since peopleGraph is a org.apache.spark.graphx.Graph object, we can use its methods to access OrientDB data, as in these examples:

val people: VertexRDD[OrientDocument] = peopleGraph.vertices
val relationships: EdgeRDD[OrientDocument] = peopleGraph.edges

println(s"The graph contains ${people.count()} vertices and ${relationships.count()} edges.\n")

 

We can also access triplets, as in this example where we print friendships among people:

peopleGraph
 .triplets
 .foreach(triplet => {
   val srcPerson: OrientDocument = triplet.srcAttr
   val dstPerson: OrientDocument = triplet.dstAttr
   println(s"Person: ${srcPerson.getString("surname")}, ${srcPerson.getString("name")} [${triplet.srcId}]. Friend: ${dstPerson.getString("surname")}, ${dstPerson.getString("name")} [${triplet.dstId}]")
 })

 

The built-in graph algorithms supplied by GraphX are also available, like the triangleCount() used here to show the triangles among people:

val triangles = peopleGraph.triangleCount()

// prints how many triangles every vertex participate in
triangles
 .vertices
 .foreach {
   case (vertexId, trianglesNumber) => println(s"Person [${vertexId}] participates in ${trianglesNumber} triangles.")
 }

 

When we have a GraphX graph and we want to save it as an OrientDB graph, we can use the saveGraphToOrient():

val gr: Graph[Person, String] = createSampleGraph(sc)
gr.saveGraphToOrient()

 

In this example, the createSampleGraph() method just creates a simple graph with three vertices and five edges as RDDs and then builds the graph upon them:

def createSampleGraph(sparkContext: SparkContext): Graph[Person, String] = {

 val people: RDD[(VertexId, Person)] =
   sparkContext.parallelize(
     Array(
       (1L, new Person("Alice", "Anderson")),
       (2L, new Person("Bob", "Brown")),
       (3L, new Person("Carol", "Clark"))
     )
   )


 val edges: RDD[Edge[String]] =
   sparkContext.parallelize(
     Array(
       Edge(1L, 2L, "Friendship"),
       Edge(1L, 3L, "Friendship"),
       Edge(2L, 1L, "Friendship"),
       Edge(3L, 1L, "Friendship"),
       Edge(3L, 2L, "Friendship")
     )
   )
 Graph(people, edges)
}

 

This full code of these examples is available on github at https://github.com/andreaiacono/SparkOrientDbConnectorDemo.

The post Using the Spark Connector for OrientDB appeared first on OrientDB Distributed Graph Database.

]]>
http://orientdb.com/spark-orientdb/feed/ 0
Configuring your OrientDB Teleporter Migration (Part 2) http://orientdb.com/teleporter-configuration-part2/ http://orientdb.com/teleporter-configuration-part2/#comments Wed, 06 Jul 2016 13:20:43 +0000 http://orientdb.com/?p=15352 London, July 6, 2016 In the previous blog post we analyzed the reasons that may lead us to configure a migration performed through OrientDB […]

The post Configuring your OrientDB Teleporter Migration (Part 2) appeared first on OrientDB Distributed Graph Database.

]]>
London, July 6, 2016

In the previous blog post we analyzed the reasons that may lead us to configure a migration performed through OrientDB Teleporter.  We have mainly seen that the issue with missing foreign keys’ definition can be overcome thanks to the mapping between logical Relationships of the source database and the Edge classes of the Graph Model. Today we’ll see that we can exploit Teleporter’s configuration even further.

Thanks to this configuration you can:

  • Add new Edge classes in the Graph Model even though Relationships are missing.
  • Modify existing mappings between Relationships and Edge classes. In fact, if the Relationship you are mapping is already present in your database, it will be overridden with the parameters you defined in the configuration.In this way you can change the name, the direction and the properties of the Edge class correspondent to a Relationship already present in the database schema.
  • Define Edge classes for join tables during a migration exploiting the aggregation strategy.

Last time we analyzed a use case where we exploited the first feature using mapping, in order to avoid that missing foreign keys in the database schema could lead to a graph database without edges.
By analyzing another use case in this blog post, we will demonstrate how take advantage of the other two functionalities.

In fact, in some instances we may want to change the default names chosen by Teleporter for the Edge classes, as they are inferred starting from the attributes’ names and they may not be so significant; we might need to add or remove properties to a specific Edge class, or want to modify the attributes of an “aggregator-edge” representing complex Relationships N-N, direction included.

Let’s suppose we have the following E-R Model:

image00

 

Then let’s presume all the foreign keys are defined in the database schema at the physical layer.
image02

 

Let’s suppose we want adopt the aggregation strategy for the migration towards OrientDB in order to aggregate the Project_Employee join table. In this way, the join table is not converted into a Vertex class but into an appropriate Edge class, and each field not involved in any relationship with other tables is aggregated in the properties of the new built edge.

Even though the new Graph Model does not reflect the original E-R Model, the aggregation leads to a great saving in terms of resources and avoids a substantial overhead as the aggregation process simplifies the structure of the resulting Graph Model, producing a simpler graph. In fact, each record in the join table will not correspond to a vertex, but an edge between two vertices.

If you want to know more about the aggregation strategy, you can refer to the documentation or you can read this article.

Therefore, performing a direct aggregating migration without any configuration we will obtain the following graph Model:

image01

 

Now suppose we want to map the following Relationships and Edge classes in a different way:

  • Aggregate-Relationship between Project and Employee: we want to invert the direction of the Project2Employee Edge class and consequently change its name to WorksAtProject. Moreover, we want to add a new role property to the Edge class properties list.
  • Relationship between Employee and Department: we want to have WorksIn as the new name for the HasDepartment Edge class and add a new since property to the Edge class.

Regarding the Relationships between Department and City, we want to maintain the default mapping, so we will not configure anything about them.

Consequently, it’s important to allow for the configuration to override the default mapping inferred and executed by Teleporter: so if you must simply change a few details in the final graph model, you will not have to write down the complete configuration, but you may just specify what you want to change.

This is the full configuration we must submit to Teleporter in order to achieve the set goals:

{
  "edges": [{
    "WorksIn": {
      "mapping": {
        "fromTable": "EMPLOYEE",
        "fromColumns": ["department"],
        "toTable": "DEPARTMENT",
        "toColumns": ["id"],
        "direction": "direct"
      },
      "properties": {
        "since": {
          "type": "DATE",
          "mandatory": true,
          "readOnly": false,
          "notNull": false
        }
      }
    },
    "WorksAtProject": {
      "mapping": {
        "fromTable": "PROJECT",
        "fromColumns": ["id"],
        "toTable": "EMPLOYEE",
        "toColumns": ["id"],
        "joinTable": {
          "tableName": "PROJECT_EMPLOYEE",
          "fromColumns": ["project_id"],
          "toColumns": ["employee_id"]
        },
        "direction": "inverse"
      },
      "properties": {
        "role": {
          "type": "STRING",
          "mandatory": true,
          "readOnly": false,
          "notNull": true
        }
      }
    }
  }]
}

 

Let’s take a closer look at each Relationship-Edge class mapping.

1. Relationship: Employee-Department, cardinality 1-N.

 "WorksIn": {
      "mapping": {
        "fromTable": "EMPLOYEE",
        "fromColumns": ["department"],
        "toTable": "DEPARTMENT",
        "toColumns": ["id"],
        "direction": "direct"
      },
      "properties": {
        "since": {
          "type": "DATE",
          "mandatory": true,
          "readOnly": false,
          "notNull": false
        }
      }
    }

 

In the configuration above we have defined which parameters must to be overridden. We decided to change the name of the Edge class through the WorksIn field, add a since property with a DATE type and maintain the original direction from Employee vertices to Department vertices.

Teleporter will recognize the Relationship you want to override on the basis of the values:

  • fromTable
  • fromColumns
  • toTable
  • toColumns

These values must to be coherent with the direction of the foreign key representing the above-mentioned Relationship. Otherwise Teleporter will interpret the relationship as a new one. So, if we want override the Relationship starting from Employee and ending with the Department Vertex class through the following configuration:

    "WorksIn": {
      "mapping": {
        "fromTable": "DEPARTMENT",
        "fromColumns": ["id"],
        "toTable": "EMPLOYEE",
        "toColumns": ["department"],
        "direction": "direct"
      }, … 

 

As result we would obtain the adding of a second relationship with an inverted direction between the two tables. Therefore, our graph model would have two Edge classes where the second one is totally wrong.
So remember to be coherent with the underlying physical schema during the mapping definition.

If you want to reverse the Edge, do not use the fromTable and toTable fields, instead take advantage of the direction field using “inverse” as value.

2. Relationship: Project-Employee, cardinality N-N.

 "WorksAtProject": {
      "mapping": {
        "fromTable": "PROJECT",
        "fromColumns": ["id"],
        "toTable": "EMPLOYEE",
        "toColumns": ["id"],
        "joinTable": {
          "tableName": "PROJECT_EMPLOYEE",
          "fromColumns": ["project_id"],
          "toColumns": ["employee_id"]
        },
        "direction": "inverse"
      },
      "properties": {
        "role": {
          "type": "STRING",
          "mandatory": true,
          "readOnly": false,
          "notNull": true
        }
      }
    }

 

The aggregation during the migration is performed on join tables which only allow join operations between two tables.

Each candidate join table is converted into an appropriate Edge class, and each attribute of the table itself is aggregated into the properties of the new built Edge. We can define this “aggregator-edge” both if foreign keys between joint table and external tables are defined or not.

If no foreign keys are defined you can kill two birds with one stone. In fact, you can declare the two Relationships with the external tables and define the mapping with an Aggregator-Edge class in one shot. Otherwise, if foreign keys are present in the schema you can act on the mapping anyway. In our example, we changed the direction of the Edge class and consequently, through the WorksAtProject field, its name as well.

The implicit direction of the Edge is set according to the fromTable and toTable fields, setting them as follows:

  • “fromTable”: “PROJECT”
  • “toTable”: “EMPLOYEE”

We decided to express the relationship between Projects and Employees through edges starting from Project vertices and ending into Employee vertices.
But we are even free to exploit the semantics of the direction field in order to reverse the direction of the final Edge, conveniently renamed WorksAtProject.
Moreover we added a role property of type STRING using the syntax already adopted for the previous mapping.

As shown in the example, in order to activate the aggregation you must define the additional joinTable field:

 "joinTable": {
          "tableName": "PROJECT-EMPLOYEE",
          "fromColumns": ["project_id"],
          "toColumns": ["employee_id"]
  }

 

This info is essential for Teleporter to infer all the single relationships between the records belonging to the “EMPLOYEE” and “PROJECT” tables and to coherently build all the edges:

  • tableName: the name of the join table which will be aggregated into the declared Edge.
  • fromColumns: the join table’s columns involved in the relationship with the “fromTable”.
  • toColumns: the join table’s columns involved in the relationship with the “toTable”.

Submitting this configuration to Teleporter, we will finally obtain the following Graph Model:

image03

 

That’s it, we achieved our goals by acting directly on the mapping between the Relationships of the source database and the Edge classes of the OrientDB graph database.

Now you are ready to start with your own data!

Stay tuned,

Gabriele Ponzi
OrientDB Ltd

References

Teleporter documentation index:
https://github.com/orientechnologies/orientdb-docs/blob/master/Teleporter-Index.md

Teleporter configuration:
https://github.com/orientechnologies/orientdb-docs/blob/master/Teleporter-Import-Configuration.md

The post Configuring your OrientDB Teleporter Migration (Part 2) appeared first on OrientDB Distributed Graph Database.

]]>
http://orientdb.com/teleporter-configuration-part2/feed/ 0