In our previous chapter, we learned how to perform various operations on documents with Arangosh, the command line. We will now learn how to perform the same operations using the web interface. To start with, put the following address – http://your_server_ip:8529/_db/song_collection/_admin/aardvark/index.html#login in the address bar of your browser. You will be directed to the following login page.

Now, enter the username and password.

If it is successful, the following screen appears. We need to make a choice for the database to work on, the _system database being the default one. Let us choose the song_collection database, and click on the green tab −

Creating a Collection

In this section, we will learn how to create a collection. Press the Collections tab in the navigation bar at the top.

Our command line added songs collection are visible. Clicking on that will show the entries. We will now add an artists’ collection using the web interface. Collection songs which we created with Arangosh is already there. In the Name field, write artists in the New Collection dialog box that appears. Advanced options can safely be ignored and the default collection type, i.e. Document, is fine.

Clicking on the Save button will finally create the collection, and now the two collections will be visible on this page.

Filling Up the Newly Created Collection with Documents

You will be presented with an empty collection on clicking the artists collection −

To add a document, you need to click the + sign placed in the upper right corner. When you are prompted for a _key, enter Affable_Balding as the key.

Now, a form will appear to add and edit the attributes of the document. There are two ways of adding attributes: Graphical and Tree. The graphical way is intuitive but slow, therefore, we will switch to the Code view, using the Tree dropdown menu to select it −

To make the process easier, we have created a sample data in the JSON format, which you can copy and then paste into the query editor area −

{“artist”: “Johnny Mercer”, “title”:”Affable Balding Me”, “composer”: “Robert Emmett Dolan”, “Year”: 1950}

(Note: Only one pair of curly braces should be used; see the screenshot below)

You can observe that we have quoted the keys and also the values in the code view mode. Now, click Save. Upon successful completion, a green flash appears on the page momentarily.

How to Read Documents

To read documents, go back to the Collections page.

When one clicks on the artist collection, a new entry appears.

How to Update Documents

It is simple to edit the entries in a document; you just need to click on the row you wish to edit in the document overview. Here again the same query editor will be presented as when creating new documents.

Removing Documents

You can delete the documents by pressing the ‘-’ icon. Every document row has this sign at the end. It will prompt you to confirm to avoid unsafe deletion.

Moreover, for a particular collection, other operations like filtering the documents, managing indexes, and importing data also exist on the Collections Overview page.

In our subsequent chapter, we will discuss an important feature of the Web Interface, i.e., the AQL query Editor.

In this chapter, we will learn the different operations with Arangosh.

The following are the possible operations with Arangosh −

• Creating a Document Collection
• Creating Documents
• Reading Documents
• Updating Documents

Let us start by creating a new database. We will use the following line of code to create a new database −

127.0.0.1:8529@_system> db._createDatabase("song_collection")
true

The following line of code will help you shift to the new database −

127.0.0.1:8529@_system> db._useDatabase("song_collection")
true

Prompt will shift to “@@song_collection”

127.0.0.1:8529@song_collection>

From here we will study CRUD Operations. Let us create a collection into the new database −

127.0.0.1:8529@song_collection> db._createDocumentCollection(''songs'')

Output

[ArangoCollection 4890, "songs" (type document, status loaded)]
127.0.0.1:8529@song_collection>

Let us add a few documents (JSON objects) to our ”songs” collection.

We add the first document in the following way −

127.0.0.1:8529@song_collection> db.songs.save({title: "A Man''s Best Friend",
lyricist: "Johnny Mercer", composer: "Johnny Mercer", Year: 1950, _key:
"A_Man"})

Output

{
   "_id" : "songs/A_Man",
   "_key" : "A_Man",
   "_rev" : "_VjVClbW---"
}

Let us add other documents to the database. This will help us learn the process of querying the data. You can copy these codes and paste the same in Arangosh to emulate the process −

127.0.0.1:8529@song_collection> db.songs.save(
   {
      title: "Accentchuate The Politics",
      lyricist: "Johnny Mercer",
      composer: "Harold Arlen", Year: 1944,
      _key: "Accentchuate_The"
   }
)

{
   "_id" : "songs/Accentchuate_The",
   "_key" : "Accentchuate_The",
   "_rev" : "_VjVDnzO---"
}

127.0.0.1:8529@song_collection> db.songs.save(
   {
      title: "Affable Balding Me",
      lyricist: "Johnny Mercer",
      composer: "Robert Emmett Dolan",
      Year: 1950,
      _key: "Affable_Balding"
   }
)
{
   "_id" : "songs/Affable_Balding",
   "_key" : "Affable_Balding",
   "_rev" : "_VjVEFMm---"
}

How to Read Documents

The _key or the document handle can be used to retrieve a document. Use document handle if there is no need to traverse the collection itself. If you have a collection, the document function is easy to use −

127.0.0.1:8529@song_collection> db.songs.document("A_Man");
{
   "_key" : "A_Man",
   "_id" : "songs/A_Man",
   "_rev" : "_VjVClbW---",
   "title" : "A Man''s Best Friend",
   "lyricist" : "Johnny Mercer",
   "composer" : "Johnny Mercer",
   "Year" : 1950
}

How to Update Documents

Two options are available to update the saved data − replace and update.

The update function patches a document, merging it with the given attributes. On the other hand, the replace function will replace the previous document with a new one. The replacement will still occur even if completely different attributes are provided. We will first observe a non-destructive update, updating the attribute Production` in a song −

127.0.0.1:8529@song_collection> db.songs.update("songs/A_Man",{production:
"Top Banana"});

Output

{
   "_id" : "songs/A_Man",
   "_key" : "A_Man",
   "_rev" : "_VjVOcqe---",
   "_oldRev" : "_VjVClbW---"
}

Let us now read the updated song”s attributes −

127.0.0.1:8529@song_collection> db.songs.document(''A_Man'');

Output

{
   "_key" : "A_Man",
   "_id" : "songs/A_Man",
   "_rev" : "_VjVOcqe---",
   "title" : "A Man''s Best Friend",
   "lyricist" : "Johnny Mercer",
   "composer" : "Johnny Mercer",
   "Year" : 1950,
   "production" : "Top Banana"
}

A large document can be easily updated with the update function, especially when the attributes are very few.

In contrast, the replace function will abolish your data on using it with the same document.

127.0.0.1:8529@song_collection> db.songs.replace("songs/A_Man",{production:
"Top Banana"});

Let us now check the song we have just updated with the following line of code −

127.0.0.1:8529@song_collection> db.songs.document(''A_Man'');

Output

{
   "_key" : "A_Man",
   "_id" : "songs/A_Man",
   "_rev" : "_VjVRhOq---",
   "production" : "Top Banana"
}

Now, you can observe that the document no longer has the original data.

How to Remove Documents

The remove function is used in combination with the document handle to remove a document from a collection −

127.0.0.1:8529@song_collection> db.songs.remove(''A_Man'');

Let us now check the song”s attributes we just removed by using the following line of code −

127.0.0.1:8529@song_collection> db.songs.document(''A_Man'');

We will get an exception error like the following as an output −

JavaScript exception in file
''/usr/share/arangodb3/js/client/modules/@arangodb/arangosh.js'' at 97,7:
ArangoError 1202: document not found
! throw error;
! ^
stacktrace: ArangoError: document not found

at Object.exports.checkRequestResult
(/usr/share/arangodb3/js/client/modules/@arangodb/arangosh.js:95:21)

at ArangoCollection.document
(/usr/share/arangodb3/js/client/modules/@arangodb/arango-collection.js:667:12)
at <shell command>:1:10

ArangoDB is hailed as a native multi-model database by its developers. This is unlike other NoSQL databases. In this database, the data can be stored as documents, key/value pairs or graphs. And with a single declarative query language, any or all of your data can be accessed. Moreover, different models can be combined in a single query. And, owing to its multi-model style, one can make lean applications, which will be scalable horizontally with any or all of the three data models.

Layered vs. Native Multi-Model Databases

In this section, we will highlight a crucial difference between native and layered multimodel databases.

Many database vendors call their product “multi-model,” but adding a graph layer to a key/value or document store does not qualify as native multi-model.

With ArangoDB, the same core with the same query language, one can club together different data models and features in a single query, as we have already stated in previous section. In ArangoDB, there is no “switching” between data models, and there is no shifting of data from A to B to execute queries. It leads to performance advantages to ArangoDB in comparison to the “layered” approaches.

The Need for Multimodal Database

Interpreting the [Fowler’s] basic idea leads us to realize the benefits of using a variety of appropriate data models for different parts of the persistence layer, the layer being part of the larger software architecture.

According to this, one might, for example, use a relational database to persist structured, tabular data; a document store for unstructured, object-like data; a key/value store for a hash table; and a graph database for highly linked referential data.

However, traditional implementation of this approach will lead one to use multiple databases in the same project. It can lead to some operational friction (more complicated deployment, more frequent upgrades) as well as data consistency and duplication issues.

The next challenge after unifying the data for the three data models, is to devise and implement a common query language that can allow data administrators to express a variety of queries, such as document queries, key/value lookups, graphy queries, and arbitrary combinations of these.

By graphy queries, we mean queries involving graph-theoretic considerations. In particular, these may involve the particular connectivity features coming from the edges. For example, ShortestPath, GraphTraversal, and Neighbors.

Graphs are a perfect fit as data model for relations. In many real-world cases such as social network, recommendor system, etc., a very natural data model is a graph. It captures relations and can hold label information with each edge and with each vertex. Further, JSON documents are a natural fit to store this type of vertex and edge data.

ArangoDB ─ Features

There are various notable features of ArangoDB. We will highlight the prominent features below −

• Multi-model Paradigm
• ACID Properties
• HTTP API

ArangoDB supports all popular database models. Following are a few models supported by ArangoDB −

• Document model
• Key/Value model
• Graph model

A single query language is enough to retrieve data out of the database

The four properties Atomicity, Consistency, Isolation, and Durability (ACID) describe the guarantees of database transactions. ArangoDB supports ACID-compliant transactions.

ArangoDB allows clients, such as browsers, to interact with the database with HTTP API, the API being resource-oriented and extendable with JavaScript.

In this chapter, we will discuss the basic concepts and terminologies for ArangoDB. It is very important to have a knowhow of the underlying basic terminologies related to the technical topic we are dealing with.

The terminologies for ArangoDB are listed below −

• Document
• Collection
• Collection Identifier
• Collection Name
• Database
• Database Name
• Database Organization

From the perspective of data model, ArangoDB may be considered a document-oriented database, as the notion of a document is the mathematical idea of the latter. Document-oriented databases are one of the main categories of NoSQL databases.

The hierarchy goes like this: Documents are grouped into collections, and Collections exist inside databases

It should be obvious that Identifier and Name are two attributes for the collection and database.

Usually, two documents (vertices) stored in document collections are linked by a document (edge) stored in an edge collection. This is ArangoDB”s graph data model. It follows the mathematical concept of a directed, labeled graph, except that edges don”t just have labels, but are full-blown documents.

Having become familiar with the core terms for this database, we begin to understand ArangoDB”s graph data model. In this model, there exist two types of collections: document collections and edge collections. Edge collections store documents and also include two special attributes: first is the _from attribute, and the second is the _to attribute. These attributes are used to create edges (relations) between documents essential for graph database. Document collections are also called vertex collections in the context of graphs (see any graph theory book).

Let us now see how important databases are. They are important because collections exist inside databases. In one instance of ArangoDB, there can be one or many databases. Different databases are usually used for multi-tenant setups, as the different sets of data inside them (collections, documents, etc.) are isolated from one another. The default database _system is special, because it cannot be removed. Users are managed in this database, and their credentials are valid for all the databases of a server instance.