New OrientDB replication engine and plans for the releasing of v. 1.6.

Hi all,
we’re glad to announce in the “develop” branch (1.6.0-SNAPSHOT) the new distirbuted configuration engine that doesn’t use Hazelcast’s Executor Service but rather Queues. This made the entire work easier (we dropped 50% of code of previous implementation) achieving better performances.
This is the new configuration in orientdb-dserver-config.xml:
    class="com.orientechnologies.orient.server.hazelcast.OHazelcastPlugin">




value="com.orientechnologies.orient.server.distributed.conflict.ODefaultReplicationConflictResolver" />


value="com.orientechnologies.orient.server.hazelcast.sharding.strategy.ORoundRobinPartitioninStrategy" />


As you can see we don’t use realignment tasks anymore: when a node comes up it get the pending messages from Hazelcast queue. This is good when a server goes up & down in a reasonable time like for a temporary network failure or an upgrade of a server. In case you plan to stop and restart the server after days you’d need to re-deploy the entire database on the server.
This is the default configuration in the new default-distributed-db-config.json file, put it under $ORIENTDB_HOME/config and remove that contained under the database if any. This configuration comes with only one partition where new joining nodes auto register themselves. So this means all the nodes have the entire database (no partitioning). To achieve better performance avoid to use a writeQuorum bigger than 2. I think having 2 servers that synchronously have the data it’s very secure. However all the server in the partition are updated, just the client receives the response when writeQuorum is reached. This is the new default configuration file:
{
"replication": true,
"clusters": {
"internal": {
"replication": false
},
"index": {
"replication": false
},
"ODistributedConflict": {
"replication": false
},
"*": {
"replication": true,
"writeQuorum": 2,
"partitioning": {
"strategy": "round-robin",
"default": 0,
"partitions": [
[ "" ]
]
}
}
}
}

Partitions contains an array of partitions as node names. The keyword “<NEW_NODE>” means that new node that joins the cluster are automatically added in that partition. 
So if you start X nodes the replication works out of the box. Thanks to the partitioning you can shard your database across multiple nodes avoiding to have a symmetric replica. So you can use your 6 servers as before:
[
  [ “node0”, “node1”, “node2”,  “node3”, “node4”, “node5” ]
]
or in this way:
[
  [ “node0”, “node1”, “node2” ],
  [ “node3”, “node4”, “node5” ]
]
It’s like RAID. With this configuration you’ve 2 partitions (0 and 1) with 3 replica each. So the database is spanned across 2 partitions automatically that means each partition owns about half database. By default we provide the “round-robin” strategy but you can already plug your one to better split the graph following your domain.
This is part of the Sharding feature, so consider it as a preview. It will be available in the next release (1.7 or 2.0).
Furthermore we’ve introduced variable timeouts that change based on the runtime configuration (number of nodes, type of replicated command, etc.)
We’ve also introduced new settings to tune the replication engine (OGlobalConfiguration class):
DISTRIBUTED_THREAD_QUEUE_SIZE(“distributed.threadQueueSize”, “Size of the queue for internal thread dispatching”, Integer.class,
      1000),

DISTRIBUTED_CRUD_TASK_TIMEOUT(“distributed.crudTaskTimeout”, “Maximum timeout in milliseconds to wait for CRUD remote tasks”,
      Integer.class, 3000),
  DISTRIBUTED_COMMAND_TASK_TIMEOUT(“distributed.commandTaskTimeout”,
      “Maximum timeout in milliseconds to wait for Command remote tasks”, Integer.class, 5000),

DISTRIBUTED_QUEUE_TIMEOUT(“distributed.queueTimeout”, “Maximum timeout in milliseconds to wait for the response in replication”,
      Integer.class, 3000),
  DISTRIBUTED_SYNCH_RESPONSES_TIMEOUT(“distributed.synchResponsesTimeout”,
      “Maximum timeout in milliseconds to collect all the synchronous responses from replication”, Integer.class, 5000),
  DISTRIBUTED_ASYNCH_RESPONSES_TIMEOUT(“distributed.asynchResponsesTimeout”,
      “Maximum timeout in milliseconds to collect all the asynchronous responses from replication”, Integer.class, 15000),

  DISTRIBUTED_PURGE_RESPONSES_TIMER_DELAY(“distributed.purgeResponsesTimerDelay”,
      “Maximum timeout in milliseconds to collect all the asynchronous responses from replication”, Integer.class, 15000);
I suggest to everybody is using the distributed architecture to upgrade to 1.6.0-SNAPSHOT and:
– update the file orientdb-dserver-config.xml and !
– update the file default-distributed-db-config.json
– remove the previous file default-distributed-db-config.json under the databases/ directory
We successfully tested the new engine against 10 servers and 200 connected clients with a writeQuorum=2 (2 synchronous copy before to give the OK to the client).
Next week we’ll release OrientDB 1.6, so you’ve last chance to vote your bugs to be in 1.6 roadmap!
Luca Garulli
CEO at Orient Technologies
the Company behind OrientDB
http://about.me/luca.garulli



London, September 2nd 2013

Mr. Claudio Tesoriero is the author of “Getting Started with OrientDB”, the new book about OrientDB. Claudio is a certified OrientDB developer that wrote this book for all the developers that want to start working with OrientDB NoSQL database.



Take a look at the Table of Contents:

Chapter 1: Installing OrientDB


Chapter 2: Administering OrientDB


Chapter 4: Performance Tuning

Chapter 5: Advanced Features




London, August 27, 2013 

Orient Technologies changed the online courses by providing a new format: 9 hours in 2 days, instead of 7 hours in only one day.  The cost of the course remains the same: £ 300.00 per attendee.

The 9 hours are split into 2 days of 4 hours each with an additional hour of off-line exercises after the first day. This change is the fruit of all the feedback received from past events where attendees reported to us that the covered topics were too many to be covered in only one day with 7 hours of non-stop learning.
                                        
We also removed the Document and Object database API portions in order to be more focused on the Blueprints API and the Graph Database concepts.

If you’re interested in taking a course, please go to: http://www.orientechnologies.com/training.htm.

Luca Garulli
CEO at Orient Technologies
the Company behind OrientDB
http://about.me/luca.garulli




OrientDB is a Graph Database “on steroids” because it supports concepts taken from both the Document Database and Object-Oriented worlds.

Take a look at this use case:  Creating a graph to map the relationships between Person and Cars.  We’re going to use the just-released OrientDB version 1.5.  

Let’s open a shell (or command prompt in Windows) and launch the OrientDB Console (use console.bat on Windows):

> cd $ORIENTDB_HOME/bin
> ./console.sh

Now we’re going to use the console to create a brand new local database:

orientdb> create database plocal:../databases/cars admin admin plocal graph

Ok, now let’s create the first graph schema with “Person” and “Car” as 2 new Vertex types and “Owns” as an Edge type:

orientdb> create class Person extends V
orientdb> create class Car extends V
orientdb> create class Owns extends E
And let’s go populate the database with the first Graph elements:
orientdb> create vertex Person set name = ‘Luca’

Created vertex ‘Person#11:0{name:Luca} v1’ in 0,012000 sec(s).

orientdb> create vertex Car set name = ‘Ferrari Modena’

Created vertex ‘Car#12:0{name:Ferrari Modena} v1’ in 0,001000 sec(s).

orientdb> create edge Owns from (select from Person) to (select from Car)

Created edge ‘[e[#11:0->#12:0][#11:0-Owns->#12:0]]’ in 0,005000 sec(s).
Ok, now we can traverse vertices. For example, what is Luca’s car? Traverse from Luca vertex to the outgoing vertices following the “Owns” relationships:
orientdb> select name from ( select expand( out(‘Owns’) ) from Person where name = ‘Luca’ )

—-+—–+————–
#   |@RID |name
—-+—–+————–
0   |#-2:1|Ferrari Modena
—-+—–+————–
Perfect. 
Now we have the location of Person and we need another Vertex type called “Country” to connect to the person with a new “Lives” Edge type:

orientdb> create class Country extends V
orientdb> create class Lives extends E


orientdb> create vertex Country set name = ‘UK’

Created vertex ‘Country#14:0{name:UK} v1’ in 0,004000 sec(s).

Next, let’s associate Luca to the UK Country:

orientdb> create edge Lives from (select from Person) to (select from Country)

Created edge ‘[e[#11:0->#14:0][#11:0-Lives->#14:0]]’ in 0,006000 sec(s).

So far so good.  Our graph has been extended. 
Now, try to search the country where there are “Ferrari” cars in our database.

orientdb> select name from ( select expand( in(‘Owns’).out(‘Lives’) ) from Car where name like ‘%Ferrari%’ )

—-+—–+—-
#   |@RID |name
—-+—–+—-
0   |#-2:1|UK
—-+—–+—-

Setting constraints on Edges

Now we’ve modeled our graph using a schema without any constraints. But it would be useful to require an Owns relationship to exist only between the Person and Car vertices. So, let’s create these constraints:

orientdb> create property Owns.out LINK Person
orientdb> create property Owns.in LINK Car

The MANDATORY setting against a property prevents OrientDB from using a lightweight edge (no physical document is created).  Be sure to pay attention and not put spaces between MANDATORY=true.

orientdb> alter property Owns.out MANDATORY=true;
orientdb> alter property Owns.in MANDATORY=true;

If we want to prohibit a Person vertex from having 2 edges against the same Car vertex, we have to define a UNIQUE index against out and in properties.

orientdb> create index UniqueOwns on Owns(out,in) unique

Created index successfully with 0 entries in 0,023000 sec(s).

Unfortunately, the index tells us 0 entries are indexed. Why?  We have already created the Owns relationships between “Luca” and “Ferrari Modena.”  In that case, OrientDB had already created a lightweight edge before we set the rule to force creation documents for Owns instances. So, you need to drop and recreate the edge.

orientdb> delete edge from #11:0 to #12:0
orientdb> create edge Owns from (select from Person) to (select from Car)

Now check that the record has been created.

orientdb> select from Owns

—-+—–+—–+—–
#   |@RID |out  |in
—-+—–+—–+—–
0   |#13:0|#11:0|#12:0

—-+—–+—–+—–

So far so good.  The constraints works.  Now try to create a “Owns” edge between Luca and UK (Country vertex):

orientdb> create edge Owns from (select from Person) to (select from Country)

Error: com.orientechnologies.orient.core.exception.OCommandExecutionException: Error on execution of command: sql.create edge Owns from (select from Person) to (sel…
Error: com.orientechnologies.orient.core.exception.OValidationException: The field ‘Owns.in’ has been declared as LINK of type ‘Car’ but the value is the document #14:0 of class ‘Country’

Now we have a typed graph with constraints. 

The next part will cover how to use polymorphism feature in the graph.

Luca Garulli, CEO

Orient Technologies, the Company behind OrientDB
http://about.me/luca.garulli




Hi everyone,
only 2 months after the release of v.1.4 (and only 1 month after the v.1.4.1 release), version 1.5 is now available for download!  


This release could actually be named 2.0 for all the various new features:

  • New PLOCAL (Paginated Local) storage engine.  In comparison with LOCAL, it’s more durable (no usage of MMAP) and supports better concurrency on parallel transactions.
  • New Hash Index type with better performance on lookups. It does not support ranges.
  • New “transactional” SQL command to execute commands inside a transaction. This is useful for the “create edge” SQL command, in order to avoid corruption of the graph
  • Import now migrates RIDs, allowing the ability to import database objects in a different one from the original 
  • Breadth first” strategy added on traversing (Java andSQL APIs)
  • Server can limit maximum live connections (to prevent DOS)
  • Fetch plan support in SQL statements and in binary protocol for synchronous commands too
  • Various bug fixes

For all the issues: https://github.com/orientechnologies/orientdb/issues?milestone=5&page=1&state=closed

For more information about the release: https://github.com/orientechnologies/orientdb/releases/tag/1.5


To receive Professional Support, please contact us at: info@orientechnologies.com.

Special thanks goes out to Artem Orobets, who just joined the Orient Technologies company, to Andrey Lomakin who has coordinated and co-developed the new PLOCAL, Hash Index and many other features on the engine part. Thanks to Luca Molino who is back on the Object Database interface. Thanks to all the contributors with their pull requests, test cases and issues who have contributed to improving OrientDB. Thanks also to the TinkerPop team for providing such cool technology to stack on top of OrientDB.


Luca Garulli
CEO at Orient Technologies
the Company behind OrientDB



London, June 19th 2013

OrientDB 1.4.1 has been released. It contains fixes to 1.4 and it’s 100% binary compatible with 1.4, so NuvolaBase suggests you to replace 1.4 with this one.
NuvolaBase Team



London, June, 7th 2013

NuvolaBase is glad to announce the new release 1.4 of OrientDB: http://www.orientdb.org/download.htm!

What’s new with 1.4?
  • Graph: total rewrite of TinkerPop Blueprints API that now are the default Java interface, support for light-weight edges (no document), labeled relationships using separate classes and vertex fields
  • Storage: new Paged-Local compressed “plocal” engine  (not yet transactional)
  • SQL: INSERT and UPDATE supports JSON syntax, improved usage of indexes upon ORDER BY, supported timeout in query and global, new create function command, flatten() now is expand(), new OSQLMethod classes to handle methods even in chain, new encode() and decode() functions, support for new dictionary: as target in SELECT and TRAVERSE
  • new SCHEDULER component using CRON syntax
  • new OTriggered class to use JS as hook
  • MMap: auto flush of pages on regular basis
  • Fetch-plan: support for skip field using “-2”
  • Index: auto rebuild in background, usage of different data-segment
  • Export: supported partial export like schema, few clusters, etc.
  • Console: improved formatting of resultsets
  • HTTP: new /batch command supporting transaction too, faster connection through /connect command, /document returns a JSON
  • StudioUML display of class

Full list: https://github.com/nuvolabase/orientdb/issues?milestone=2&state=closed


Issues

To report an issue please follow the suggestions posted in the group, in particular attach the following information:
  • OrientDB version. Please don’t forget this! If it’s a SNAPSHOT please tell if it’s from SVN (revision number) or from MAVEN
  • Operative System
  • 32-bit or 64-bit
  • JVM version
  • RAM
  • Dump of configuration and profiler

Professional Services
All the professional services are provided by NuvolaBase.com Ltd, London UK.

Partnership
If your company is skilled on using OrientDB and want to be a partner as “reseller” or better a “services partner” please contact info@nuvolabase.com to have more information.

Roadmap
Release 2.0 can wait. We planned an intermediate version 1.5 to release in about one month (mid July 2013) with many things we have postponed.


Thanks to all the committers, the contributors and final users!

Enjoy with Graphs,
Orient Technologies & NuvolaBase Teams




London, April 4th 2013

After about one month spent on development and test the NuvolaBase team has released the new GraphDB Engine!

The new Engine uses some novel techniques based on the idea of a dynamic Graph that change shape at run-time based on the settings and content. The new Engine is much faster than before and needs less space in memory and disk. Below the main improvements:

  1. avoid creation of edges as document if haven’t properties. With Graphs wit no properties on edges this can save more than 50% of space on disk and therefore memory with more chances to have a big part of database in cache. Furthermore this speed up traversal too because requires one record load less. As soon as the first property is set the edge is converted transparently
  2. Vertex “in” and “out” fields aren’t defined in the schema anymore because can be of different types and change at run-time adapting to the content:
    1. no connection = null (no space taken)
    2. 1 connection = store as LINK (few bytes)
    3. >1 connections = use the Set of LINKS (using the MVRBTreeRIDSet class)
  3. binding of Blueprints “label” concept to OrientDB sub-classes. If you create an edge with label “friend”, then the edge sub-type “friend” will be used (created by the engine transparently). This means:
    1. 1 field less in document (the field “label”) and therefore less space and the ability to use the technique 1 (see above)
    2. edges are stored on different files at file system level because are used different clusters
    3. better partitioning against multiple disks (and in the future more parallelism)
    4. direct queries like “select from friend” rather than “select from E” and then filtering the result-set looking for the edge with the wanted label property
  4. multiple properties for edges of different labels. Not anymore a “in” and “out” in Vertex but “out_friend” to store all the outgoing edges of class “friend”. This means faster traversal of edges giving one or multiple labels avoiding to scan the entire Set of edges to find the right one
  5. with such dynamic Graph in future we could support also HyperGraph in a flash
Such new Engine needed new API or a radical change to the current Raw API breaking the compatibility with the past. Well, we decided to change strategy by re-implementing the Blueprints Graph layer as new GraphDB Engine. So the new GraphDB Engine IS the OrientDB’s Blueprints implementation.
Why? Mainly because:
  1. Blueprints is the de facto standard for Graph Databases made by TinkerPop team
  2. TinkerPop team is amazing with a lot of technologies built on top of Blueprints layer
  3. Latest release of Blueprints added some new features to allow the implementations to use the underlying engine in more powerful way
  4. Blueprints API and all the TinkerPop stack is very well documented with a lot of examples and a new Book that is coming
The new GraphDB engine depends on OrientDB 1.4.0-SNAPSHOT, so we can’t push it to TinkerPop repository because no SNAPSHOT are allowed as dependencies. As soon as we release OrientDB 1.4 we’re going to merge it with official TinkerPop Blueprint’s repository.
Starting from OrientDB 1.4 the GraphDB API to use are the Blueprints. Period. I’m sure this will make happy some users because Raw API are horrible and you’ve to work at document level using the OGraphDatabase class for any operations against vertices and edges (not really Object Oriented).
Waiting for the official release you can enjoy by cloning and start using the new GraphDB Engine from the master branch of NuvolaBase’s Blueprints fork: https://github.com/nuvolabase/blueprints. It passes all the Blueprints Test Cases.
To open databases created with previous releases uses:
OrientGraph graph = new OrientGraph(“local:/temp/mydb”);
graph.setUseLightweightEdges(false);
graph.setUseVertexFieldsForEdgeLabels(false);
graph.setUseCustomClassesForEdges(false);
In the next days will be released a new tool to convert the databases to the new format.

Luca Garulli
CEO at NuvolaBase.com
the Company behind OrientDB
Follow me on http://twitter.com/lgarulli




London, November, 21st 2012
NuvolaBase is glad to announce this new release 1.3 and the new Web Site of OrientDB: http://www.orientdb.org!

Sorry for the delay about this official email, but we did extra work after the switch from Google Code to GitHub. Thank you to all the contributors helped us in this migration, specially Adrian Madrid for the adapted WiKi pages. In the next days we’re going to improve the documentation by involving all the authors of Drivers to contribute with a short tutorial and a quick reference for the usage of the driver.

What’s new with 1.3?

  • SQL: new eval() function to execute expressions
  • SQL: new if() and ifnull() functions
  • SQL: supported server-side configuration for functions
  • SQL: new DELETE VERTEX and DELETE EDGE commands
  • SQL: execution of database functions from SQL commands
  • SQL: new create cluster command
  • Graph: bundled 2 algorithms: Dijkstra and ShortestPath between vertices
  • Performance: improved opening time when a connections is reused from pool
  • Performance: better management of indexes in ORDER BY
  • Schema: new API to handle custom fields
  • HTTP/REST: new support for fetch-plan and limit in “command”
  • Moved from Google Code to GitHub: https://github.com/nuvolabase/orientdb
  • Many bugs fixed
Full list: Full list: https://github.com/nuvolabase/orientdb/issues?milestone=1&page=1&state=closed 

Issues

To report an issue please follow the suggestions posted in the group, in particular attach the following information:
  • OrientDB version. Please don’t forget this! If it’s a SNAPSHOT please tell if it’s from SVN (revision number) or from MAVEN
  • Operative System
  • 32-bit or 64-bit
  • JVM version
  • RAM
  • Dump of configuration and profiler
To open a new issue: https://github.com/nuvolabase/orientdb/issues/new
Professional Services
All the professional services are provided by NuvolaBase.com Ltd.
Partnership
We built a new Partnership Agreement for companies interested to sell NuvolaBase or OrientDB services as “reseller” or “services partner”. Please contact info@nuvolabase.com to have more information about it.
Roadmap
The roadmap has been updated -> https://github.com/nuvolabase/orientdb/issues/milestones. The next release will be the 1.4 planned for January 2013 and then the long awaited 2.0 with the new distributed architecture with auto-sharding and parallel queries.
Thanks to all the committers, the contributors and final users.




Introduction

This tutorial explains step-by-step how to create partitioned graphs using the Record Level Security feature introduced in OrientDB 1.2.0. This feature is so powerful we can totally separate database’s records as sand-boxes where each “Restricted” records can’t be accessed by non authorized users. This tutorial demonstrates this sand-boxes works well also with the GraphDB API and the TinkerPop stackPartitioning graphs allows to build real Multi-tenant applications in a breeze.

Requirements:


Index of contents

Create a new empty graph database

First open the console of the GraphDB Edition and create the new database “blog” of type “graph” against the local file-system:
$ cd $ORIENTDB_HOME/bin
$ console
.shOrientDB console v.1.2.0-SNAPSHOT www.orientechnologies.comType 'help' to display all the commands supported.
Installing extensions for GREMLIN language v.2.2.0-SNAPSHOT

orientdb
> create database local:../databases/blog admin admin local graphCreating database [local:../databases/blog] using the storage type [local]...
Database created successfully.
Current database is: local:../databases/blog

Enable graph partitioning

Now turn on partitioning against graph by letting classes V (Vertex) and E (Edge) to extend the ORestricted class. In this way any access to Vertex and Edge instances can be restricted:
orientdb> alter class V superclass ORestrictedClass updated successfully

orientdb
> alter class E superclass ORestricted
Class updated successfully

Create 2 users

Now let’s go creating 2 users: “luca” and “steve”. First ask the current roles in database to know the “writer” role’s rid:
orientdb> select from orole
---+---------+--------------------+--------------------+--------------------+--------------------
 
#| RID     |name                |mode                |rules               |inheritedRole
---+---------+--------------------+--------------------+--------------------+--------------------
 
0|     #4:0|admin               |1                   |{}                  |null
 
1|     #4:1|reader              |0                   |{database=2, database.schema=2, database.cluster.internal=2, database.cluster.orole=2, database.cluster.ouser=2, database.class.*=2, database.cluster.*=2, database.command=2, database.hook.record=2}|null
 
2|     #4:2|writer              |0                   |{database=2, database.schema=7, database.cluster.internal=2, database.cluster.orole=2, database.cluster.ouser=2, database.class.*=15, database.cluster.*=15, database.command=15, database.hook.record=15}|null
---+---------+--------------------+--------------------+--------------------+--------------------
3 item(s) found. Query executed in 0.045 sec(s).
Found it, it’s the #4:2. Not create 2 users with as first role #4:2 (writer):
orientdb> insert into ouser set name = 'luca', status = 'ACTIVE', password = 'luca', roles = [#4:2]
Inserted record 'OUser#5:4{name:luca,password:{SHA-256}D70F47790F689414789EEFF231703429C7F88A10210775906460EDBF38589D90,roles:[1]} v1' in 0,001000 sec(s).

orientdb
> insert into ouser set name = 'steve', status = 'ACTIVE', password = 'steve', roles = [#4:2]
Inserted record 'OUser#5:3{name:steve,password:{SHA-256}F148389D080CFE85952998A8A367E2F7EAF35F2 D72D2599A5B0412FE4094D65C,roles:[1]} v1' in 0,001000 sec(s).

Create a simple graph as user ‘Luca’

Now it’s time to disconnect and reconnect to the blog database using the new “luca” user:
orientdb> disconnect
Disconnecting from the database [blog]...OK

orientdb
> connect local:../databases/blog luca lucaConnecting to database [local:../databases/blog] with user 'luca'...OK
Now create 2 vertices: a Restaurant and a Pizza:
orientdb> create vertex set label = 'food', name = 'Pizza'
Created vertex 'V#9:0{label:food,name:Pizza,_allow:[1]} v0' in 0,001000 sec(s).

orientdb
> create vertex set label = 'restaurant', name = "Dante's Pizza"
Created vertex 'V#9:1{label:restaurant,name:Dante's Pizza,_allow:[1]} v0' in 0,000000 sec(s).
Now connect these 2 vertices with an edge labelled “menu”:
orientdb> create edge from #9:0 to #9:1 set label = 'menu'
Created edge '[E#10:0{out:#9:0,in:#9:1,label:menu,_allow:[1]} v1]' in 0,003000 sec(s).
To check if everything is ok execute a select against vertices:
orientdb> select from v
---+---------+--------------------+--------------------+--------------------+--------------------
 
#| RID     |label               |name                |_allow              |out
---+---------+--------------------+--------------------+--------------------+--------------------
 
0|     #9:0|food                |Pizza               |[1]                 |[1]
 
1|     #9:1|restaurant          |Dante's Pizza       |[1]                 |null                |[1]
---+---------+--------------------+--------------------+--------------------+--------------------+--------------------
2 item(s) found. Query executed in 0.034 sec(s).

Create a simple graph as user ‘Steve’

Now let’s connect to the database using the ‘Steve’ user and check if there are vertices:
orientdb> disconnect
Disconnecting from the database [blog]...OK

orientdb
> connect local:../databases/blog steve steveConnecting to database [local:../databases/blog] with user 'steve'...OK

orientdb
> select from v
0 item(s) found. Query executed in 0.0 sec(s).
Ok, no vertices found. Try to create something:
orientdb> create vertex set label = 'car', name = 'Ferrari Modena'
Created vertex 'V#9:2{label:car,name:Ferrari Modena,_allow:[1]} v0' in 0,000000 sec(s).

orientdb
> create vertex set label = 'driver', name = 'steve'
Created vertex 'V#9:3{label:driver,name:steve,_allow:[1]} v0' in 0,000000 sec(s).

orientdb
> create edge from #9:2 to #9:3 set label = 'drive'
Created edge '[E#10:1{out:#9:2,in:#9:3,label:drive,_allow:[1]} v1]' in 0,002000 sec(s).
Now check the graph just created:
orientdb> select from v
---+---------+--------------------+--------------------+--------------------+--------------------
 
#| RID     |label               |name                |_allow              |out
---+---------+--------------------+--------------------+--------------------+--------------------
 
0|     #9:2|car                 |Ferrari Modena      |[1]                 |[1]
 
1|     #9:3|driver              |steve               |[1]                 |null                |[1]
---+---------+--------------------+--------------------+--------------------+--------------------+--------------------
2 item(s) found. Query< span> executed in 0.034 sec(s).
The “Steve” user doesn’t see the vertices and edges creates by other users!
What happen if we try to connect 2 vertices of different users?
orientdb> create edge from #9:2 to #9:0 set label = 'security-test'

Error: com.orientechnologies.orient.core.exception.OCommandExecutionException: Error on execution of command: OCommandSQL [text=create edge from #9:2 to #9:0 set label = 'security-test']
Error: java.lang.IllegalArgumentException: Source vertex '#9:0' does not exist
The partition is totally isolated and OrientDB thinks the vertex doesn’t exist while it’s present, but invisible to the current user.

TinkerPop Stack

Record Level Security feature is very powerful because acts at low level inside the OrientDB engine. This is why everything works like a charm, even the TinkerPop stack.

Now try to display all the vertices and edges using Gremlin:
orientdb> gremlin g.V
[v[#9:2], v[#9:3]]
Script executed in 0,448000 sec(s).
orientdb
> gremlin g.E

e
[#10:1][#9:2-drive->#9:3]
Script executed in 0,123000 sec(s).

The same is using other technologies that use the TinkerPop Blueprints: TinkerPop RexterTinkerPop PipesTinkerPop FurnaceTinkerPop Frames and ThinkAurelius Faunus.


This tutorial has been published in http://code.google.com/p/orient/wiki/PartitionedGraphs.





Take your enterprise to the next level with OrientDB