THE DATABASE THAT SYNCS

Have you ever dream with a database to make data shared applications easily?

Stop dreaming, It’s here.  abetooDB is a NoSQL document oriented distributed database that syncs.

• It’s a NoSQL database because it doesn’t follow the standards about SQL syntax and access paradigm, but It has a powerful set of classes that covers both CRUD operations and Query requests.
• It’s Document oriented because you can work in a more natural way, persisting objects as a collection of properties. But unlike MongoDB you can modify the schema over the fly, modifying , inserting or deleting properties, most of times, without to rewrite any single line of code.
• And It’s distributed because data is not at a central database, but distributed between the whole devices.

abetooDB is serverless because the whole data available is distributed between devices, data are where they’re needed. But what about if a device is broken or is stolen, no problem, with abetooDB you can have as many replica devices as you want.

abetooDB is based on some well-known technologies present in the market long time ago. The persistence layer is based on SQLite and the sync protocol is based on the last version of the  Stomp protocol. That’s the reason why unlike databases like Couchbase Lite which is HTTP based, abetooDB can sync devices peer-to-peer everywhere they are.

Security is one of our main concern, that’s the reason why every single sync connection is encrypted using a 256-bit SSL certificate and authenticated with an username/password challenge.

Throughout the rest of chapters we will see each and every one of these characteristics and much more in detail.

Chocrón J.

abetooDB is not intended to be used in every single application. There are many applications where the traditional Server-centric approach fits better.

If your application need to access to a big repository of enterprise data, need a high degree of concurrency and scalability centralized in a single point, don’t use abetooDB, use a data engine like Oracle or MySQL with a regular client/server approach. abetooDB is trying to solve a completely different problem. But if your application need to access locally generated data and need to share them across other devices in a simple an efficient manner, then go with abetooDB. abetooDB emphasizes economy, efficiency, reliability, independence, and simplicity.

Scenarios that fits well with abetooDB,

• Embedded devices

abetooDB is a good fit for use in devices like cellphones, set-top boxes, televisions, game consoles, cameras, watches, kitchen appliances, thermostats, automobiles, machine tools, remote sensors, drones, and robots: the “internet of things”, sharing information in real time with each other.

• Websites

abetooDB works great as the database engine for most low to medium traffic websites. The amount of web traffic that abetooDB can handle depends on how heavily the website uses its database. Generally speaking, any site that gets fewer than 100K hits/day should work fine with abetooDB .

In order to download and install any abetooDB package you need to add the public nuget feed repository, please follow this steps.

Enter into Tools->NuGet Package Manager->Package Manager Settings

From NuGet Package Manager select Package Sources,

Then press to the plus button to add a new repository with the following information,

In the name section add “abetooDB package source” or whatever to uniquely identify the repository source, the most important thing is to include the source with https://www.myget.org/F/abetoodb/api/v2/, then click Update and OK.

To check if the installation was right, let’s list the packages available in the repository.

Open the “Manage NuGet Packages for solution” window, open the Package source combobox and select “abetooDB package source”, or whatever you called it before.

And you have to receive a list of all the abetoodb packages available.

You’re done to start programming. 😉

Create a new project under Visual Studio. In the following example a new console project is created.

Once the project is created, open the NuGet window and look for abetooDB package. Install it.

Once you’ve added the abetooDB package and dependencies you’re done to start coding.

Add the following code to your main file,

class Program
{
   static void Main(string[] args)
   {
      // Instantiate a new database
      AbtooDB dbA = AbtooDB.getDB("databaseA");

      // Insert a new document
      AbtooDocument doc = AbtooDocument.createDocument(dbA, "cars");
      Dictionary<string, object> properties = 
         new Dictionary<string, object>();
      properties.Add("color", "RED");
      properties.Add("HP", 120);
      properties.Add("airbag", true);
      doc.update(properties);

      // Retrieve persisted doc from DB
      AbtooDocument docdb = AbtooDocument.getDocById(dbA, doc.DocId);
      
      // Show property value from document
      Console.WriteLine(docdb.getString("color"));
   }
}

And if you launch the app you’ll get the following result,

Create a new project under Visual Studio. In the following example a new Android, Blank App, project is created,

Once the project is created, open the NuGet window and look for XabetooDB package. Install it.

Click on Project->Properties

Then click on Android Options->Advanced

And finally Select Native TLS 1.2+ and close

Once you’ve added the XabetooDB package and dependencies you’re done to start coding.

In order to check if you’ve installed it properly, add the following code to your main file and launch it,

[Activity(Label = "AndroidTestApp", MainLauncher = true, Icon = "@drawable/icon")]
public class MainActivity : Activity
{
   public static string DB_NAME = System.Environment.GetFolderPath(System.Environment.SpecialFolder.ApplicationData) + "/abtootest";

   protected override void OnCreate(Bundle bundle)
   {
      base.OnCreate(bundle);
      // Set our view from the "main" layout resource
      SetContentView (Resource.Layout.Main);
      
      // Create/open the database
      AbtooDB database = AbtooDB.getDB(DB_NAME);

      // Create and persist a new document
      AbtooDocument doc = AbtooDocument.createDocument(database, "cars");
      Dictionary<string, object> props = new Dictionary<string, object>();
      props.Add("prop1", "prop1value");
      doc.update(props);
   }
}

This code simply declare a database and save a document to it.

Work in progress.

Due to the fact that abetooDB is a document oriented database, everything is related to the document. So in this lesson you are going to learn the basis of the document interiors, how to define a relationship between documents and how It works behind the scenes.

Whenever you create a new document in the database, in addition to the type and the properties of the document itself, an ID is associated with it. This ID is unique and it doesn’t change along the live of the document. Even modifying the document, its ID remains inmutable. This is a very important fact because abetooDB works using MVCC (Multi Version Concurrency Control) and the ID is the reference used to be able to identify every document. Once a document is created the current timestamp is also saved, so you can know at any give time when a document was created.

As It was said before when you create a new document an ID is associated, but on the other hand whenever you make any CRUD (Create-Read-Update-Delete) operation, over an existent document, a new Revision is associated with it. Every Revision ID is also unique along the document. That way is possible to keep track about changes made over a single document along the time. This subject will be very important in the lesson of Conflict detection and resolution. With every single Revision the current timestamp is also saved.

Unlike any other database, the Delete operation over a document doesn’t delete it from the database, it only marks the document as a deleted document. It means that you aren’t going to get it in your querys anymore, but the document is still present in the database. And you may wonder why?. You don’t have to forget that abetooDB is a distributed database, If the document were simply deleted, How would this change be synced to other  databases?. Of course there is a method to completely remove a document from a database, but this change will not be synced.

So one single document has a collection of properties, an unique ID, a type, a timestamp, a deleted mark and could have zero, one or more Revisions, every single one with its own properties, timestamp and deleted mark.

The document type is just a string and define the class of document is inside. The document properties are JSON-like field-value pairs, so you can define a set of properties like any other regular JSON object,

Let’s define, as an example, a car document with ID ‘ab1’ and type ‘cars’.

{
   color: "RED",
   hp: 90,
   airbag: True
}

But what about if we’d like to create a set of colors and reference the color of the car to one of them,

Let’s define a color document with ID ‘cc1‘ and type ‘colors’

{
   color: "RED", 
   price: 12, 
   stock: True 
}

And now rewrite the car document to reference it,

{
   color: "cc1", 
   hp: 90, 
   airbag: True 
}

Look how the color field is now the document color ID we like to reference.

In the Document lesson all of these topics will be discussed more.

A database is a collection of documents logically related. Every document CRUD operation is done against a single database. A document always is owned by one and only one database. It’s represented by the class AbtooDB.

Create a database

To instantiate a new database you can use this line,

AbtooDB dbA = AbtooDB.getDB("databaseA");

If the database exists, It’ll be openned otherwise It’ll be created first. You can add a set of configuration parameters to use an encrypted database, to make it read only or to change the default Path.

Database parameters

To add any optional parameters to the database you’ve to instantiate an AbtooDBConfiguration object. Notice how you can add whatever parameters you want regardless of the order they occupy.

As an example, this sentence only define an encryption key for the database,

AbtooDBConfiguration abconfig = new AbtooDBConfiguration() 
{ 
   encryptionKey = "1ead17d51251f689aea1779d5203" 
};
AbtooDB dbA = AbtooDB.getDB("databaseA", abconfig);

If you want to change the default Path and make it readonly you can use the following sentence,

AbtooDBConfiguration abconfig = new AbtooDBConfiguration() 
{ 
   path = "C:\\path\\db\\", 
   readOnly = true
};
AbtooDB dbA = AbtooDB.getDB("databaseA", abconfig);

And using the full options,

AbtooDBConfiguration abconfig = new AbtooDBConfiguration() 
{ 
   encryptionKey = "1ead17d51251f689aea1779d5203",
   path = "C:\\path\\to\\db\\",
   readOnly = false
};
AbtooDB dbA = AbtooDB.getDB("databaseA", abconfig);

The default options are readonly false, no encryption and the default path is platform dependant, usually the same app folder.

How to change a database encryption key?

First open the database as usual, if the database is encryptedless don’t use any encryption key in the opening process, if the database is encrypted use the original key. For example here is an example of an encrypted database and how to change the encryption key.

AbtooDBConfiguration abconfig = new AbtooDBConfiguration() 
{
   encryptionKey = "ONEencryptionkey",
};
AbtooDB dbA = AbtooDB.getDB("encrypteddb", abconfig);
dbA.changeEncryptionKey("OTHERencryptionkey");

Once the key was changed you have to use it whenever you open the database. For this example, for any afterward opening operation you have to do something like that,

AbtooDBConfiguration abconfig = new AbtooDBConfiguration() 
{
   encryptionKey = "OTHERencryptionkey",
};
AbtooDB dbA = AbtooDB.getDB("encrypteddb", abconfig);

Notice how the opening encryption key was changed.

How to Know if a database exists?

You can get if a database is ready created with the following sentence,

bool dbexists = AbtooDB.Exists("encrypteddb");

Notice that if the database is in other path than the default one you have to include the full path.

How to know how many documents are within the database?

There’s a method to get the number of documents available within the database, just launch the following sentence,

AbtooDB dbA = AbtooDB.getDB("testdb");
int numdocs = dbA.getDocCount();

Launching this sentence you’ll get only the docs that are not yet deleted, if you want to include also the deleted ones, just modify the sentence that way,

int numdocs = dbA.getDocCount(true);

Database changes listener

abetooDB has a mechanism to track any change that take place within the database. You only have to add an event handler to the OnChange event. This is a very powerful mechanism because allows you trigger an action whenever a new document is inserted/modified by your app or by any sync process running in the background with external data.

As an example let’s define a new database with a event handler this way,

AbtooDB dbA = AbtooDB.getDB("testdb");
dbA.OnChange += ((obj, docslist) =>
{
   Console.WriteLine("Changes count:" + docslist.Count);
});

Using this code whenever a new document is inserted or modified, a new line with the total number of changes is printed on the screen. Notice how what you are actually receiving is a collection of modified/inserted documents.

You can also use this listener to keep a track over a single document you are interested in.

AbtooDB dbA = AbtooDB.getDB("testdb");
dbA.OnChange += ((obj, docslist) =>
{
   foreach (var doc in docslist)
   {
      if (doc.DocId == "xxxxxxxxxxxxxxxxxxxxx")
      {
         Console.WriteLine("New change over DocID:" + doc.DocId);
      }
   } 
});

… or you can also define an action whenever any of the documents belong to a particular type.

AbtooDB dbA = AbtooDB.getDB("testdb");
dbA.OnChange += ((obj, docslist) =>
{
   foreach (var doc in docslist)
   {
      if (doc.DocType == "cars")
      {
         Console.WriteLine("Change on a doc:" + doc.DocId);
      }
   } 
});

… or maybe you are interested only in documents recently created,

AbtooDB dbA = AbtooDB.getDB("testdb");
dbA.OnChange += ((obj, docslist) =>
{
   foreach (var doc in docslist)
   {
      if (doc.getDocTimeStamp() > DateTime.Now.AddDays(-2))
      {
         Console.WriteLine("Change on a doc:" + doc.DocId);
      }
   } 
});

The AbtooDB object plays an important role in other aspects of the database, like the replication mechanism and the conflict resolution algorithm among others. Every single one will be introduced in the next lessons.

The Document is the cornerstone of abetooDB database. Almost every single action you can make with abetooDB is somehow related with documents.

Create a Document, Access to its Properties

You can instantiate a new Document object with the following sentence,

AbtooDB dbA = AbtooDB.getDB("testdb");
AbtooDocument doc = AbtooDocument.createDocument(dbA, "cars");

But It doesn’t mean that this new object is persisted to the database, to do that you need to save a set of properties,

Dictionary<string, object> properties = new Dictionary<string, object>();
properties.Add("color", "RED");
properties.Add("HP", 120);
properties.Add("airbag", true);
doc.update(properties);

You can also get a document from a database using its ID,

AbtooDocument samedoc = AbtooDocument.getDocById(dbA, doc.DocId);

In this particular case doc and samedoc are referencing to the same document.

Every document has some inner information that could be interesting for different purposes,

• An unique identifier , DocId.
• The type the document belongs to, DocType.
• The current revision, CurrentRevision.
• A collection of old revisions, HistoryRevisions.
• A collection of conflict revisions, ConflictRevisions.

Every revision contains the following information,

• An unique identifier, RevId.
• A mark to indicated if it’s a deleted revision, Deleted.
• A set of field-value properties, Properties.

Notice how the actual collection of properties is contained in the CurrentRevision, nevertheless you can access this properties directly through a set of document methods.

Once you have defined a document like the previous one, you can access its properties this way,

object colorproperty = doc.getProperty("color");

Then you can do a casting to obtain the underlying string content,

string strcolorproperty = colorproperty as string;

… but abetooDB has a shortcut that allows you to get the string property directly,

string colorproperty = doc.getString("color");

That way if the underlying content of the property is a string you’ll get the string value directly otherwise you’ll get a null. Note that if the property doesn’t exists you’ll get a null too.

This is exactly the same if we’d have done the following operations,

object colorproperty = doc.CurrentRevision.getProperty("color") as string;

… or faster,

string colorproperty = doc.CurrentRevision.getString("color");

Notice how accessing properties through the methods of the document is faster.

string colorproperty = doc.getString("color");
string colorproperty = doc.CurrentRevision.getString("color");

Before access any property you may want to check if the property exists, you can do so with this sentence,

bool propertyColorExists = doc.hasProperty("color");

There are another accessors for other property types,

Int64? hpproperty = doc.getInt("HP");
bool? airbagproperty = doc.getBool("airbag");

Notice how the “?” symbol is due to the fact that the return value can be null, if the underlying property does not exists or the conversion cannot be done.

How to access related documents?

We now know how to create a document and how to access to its properties, but what about if we want to define a relational link between two documents.

Let’s explain the question with an example, let’s define a type “cars” document with the following properties,

AbtooDocument doc = AbtooDocument.createDocument(dbA, "cars");
Dictionary<string, object> properties = new Dictionary<string, object>();
properties.Add("color", "RED");
properties.Add("CV", 120);
properties.Add("airbag", true);
doc.update(properties);

What we want is to define a set of colors where we can define more information about its price and availability, and then we want to reference the car color property to one of this new color document, let’s do it.

First we’ve to define a color document,

AbtooDocument colordoc = AbtooDocument.createDocument(dbA, "colors");
Dictionary<string, object> properties = new Dictionary<string, object>();
properties.Add("color", "RED");
properties.Add("price", 30);
properties.Add("available", true);
colordoc.update(properties);

… and now we can redefine our car document this way,

AbtooDocument cardoc = AbtooDocument.createDocument(dbA, "cars");
Dictionary<string, object> carproperties = new Dictionary<string, object>();
carproperties.Add("color", colordoc.DocId);
carproperties.Add("HP", 120);
carproperties.Add("airbag", true);
cardoc.update(carproperties);

Notice how now we put the color document id DocId where we want to establish the relational link between the two documents.

Now we can access the color document properties like the price and the availability through the car document this way,

string color = cardoc.getString("color.color"); // RED
Int64? price = cardoc.getInt("color.price"); // 30
bool? available = cardoc.getBool("color.available"); // true

Notice how to be able to access the color document properties, we’ve to indicate the car property and the color property separated by a dot.

Access to the Timestamp of a Document or a Revision

Whenever a new document or a revision is created, the current timestamp is saved with them.

We can access to the time when a document was created with this sentence,

DateTime dt = cardoc.getDocTimeStamp();

… on the other hand we can access to the time when the current revision was created this way,

DateTime currentRevTS = cardoc.getCurrentRevisionTimeStamp();

But we can also access to any other timestamp of the HistoryRevisions or ConflictRevisions, simply iterate or get the revision you want. (Notice that the document need to have almost one old/conflict revision, you can check the number of historical revision calling to cardoc.HistoryRevisions.Count)

DateTime revst = cardoc.HistoryRevisions[0].getTimeStamp();

Delete a document

Delete a document from the abetooDB database don’t actually remove it, it means that this document will be marked as a deleted document. This is due to the fact that abetooDB is a distributed database and in order to be able to replicate this change, the document has to be available for future syncs.

We can delete a document this way,

cardoc.delete();

Once we’ve deleted a document, it won’t appear again in any query, but if this document is modified in another external database, before the sync process take place, and synced later with the local database, the document could appear again as if it wouldn’t had been deleted. Normally this kind of situation triggers a conflict, we’ll discuss about this subject in the Conflicts lesson.

If we want to completely remove a document from the database, you can do it this way,

cardoc.remove();

But we have to take into account that this change won’t be synced with any other database, so be careful with that. Normally we’ll only remove documents used temporarily. Remove a document completely eliminate the document and all the revisions.

How Can I modify a document properties along the revisions?

Once a new set of properties are saved as a new Revision for a document, you can access any of the older versions of the documents through the HistoryRevisions property. HistoryRevisions property is a collection of old revisions and, although usually, all of them will include the same properties, you can add,remove or modify the set of properties in every single new revision.

You don’t have to do anything special to adapt to any change made over the schema, abetooDB by its nature is schemaless, if you have to add a new property to a document type, simply include it in the next revision.

As an example, let’s create a new document,

// Instantiate a new database
AbtooDB dbA = AbtooDB.getDB("testdb");
 
// Insert a new document
AbtooDocument cardoc = AbtooDocument.createDocument(dbA, "cars");
Dictionary<string, object> properties = new Dictionary<string, object>();
properties.Add("color", "RED");
properties.Add("HP", 130);
properties.Add("airbag", true);
cardoc.update(properties);

… and then persist a new revision changing the properties,

properties = new Dictionary<string, object>();
properties.Add("color", "BLUE");
properties.Add("doors", 5);
properties.Add("gps", false);
cardoc.update(properties);

Now if we try to access to the “HP” or “airbag” properties, we’re going to get a null value, meaning these properties don’t exists anymore,

Int64? hp = cardoc.getInt("HP");
bool? airbag = cardoc.getBool("airbag");
Console.WriteLine(hp == null); // true
Console.WriteLine(airbag == null); // true
Console.WriteLine(cardoc.hasProperty("HP")); // false
Console.WriteLine(cardoc.hasProperty("airbag")); // false

Our document has two new properties, lose two and keeps the “color” property alive. We can access to the actual set of properties this way,

Console.WriteLine(cardoc.getString("color")); // BLUE
Console.WriteLine(cardoc.getInt("doors")); // 5
Console.WriteLine(cardoc.getBool("gps")); // false

If we want to access to the old set of properties, we have to access to the collection of old revisions (HistoryRevisions) and pick the first one, this will be the most recent,

Console.WriteLine(cardoc.HistoryRevisions[0].getString("color")); // RED
Console.WriteLine(cardoc.HistoryRevisions[0].getInt("HP")); // 130
Console.WriteLine(cardoc.HistoryRevisions[0].getBool("airbag")); // true

What’s the meaning of the ConflictRevisions property?

Whenever a new conflict is trigger on a Document within the database, these conflicts are stored as a collection of conflicting revisions and are accesible throught the ConflictRevisions property. These conflict revisions are sorted by order of arrival, first are the most recent. We’re going to dig into this topic later on the Conflicts lesson, where we’re going to learn how to detect new conflicts and how to solve them.

abetooDB has a powerful growing set of Query methods. Pretty similar to the SQL query construction basis but with the focus on documents.

With abetooDB there’re two types of Querys,

• DocumentQuery.
• AggregationQuery.

DocumentQuery

Whenever you launch a DocumentQuery, you’re going to get a collection of documents that fit some predefined conditions.

As an example let’s define a database with some documents,a new database

AbtooDB dbA = AbtooDB.getDB("testquerydb");

// Insert two Color documents
AbtooDocument colorRedDoc = AbtooDocument.createDocument(dbA, "colors");
Dictionary<string, object> properties = new Dictionary<string, object>();
properties.Add("color", "Red");
properties.Add("price", 30);
properties.Add("available", true);
colorRedDoc.update(properties);

AbtooDocument colorBlueDoc = AbtooDocument.createDocument(dbA, "colors");
properties = new Dictionary<string, object>();
properties.Add("color", "Blue");
properties.Add("price", 19);
properties.Add("available", false);
colorBlueDoc.update(properties);

// Insert two car documents
AbtooDocument carVWdoc = AbtooDocument.createDocument(dbA, "cars");
properties = new Dictionary<string, object>();
properties.Add("color", colorRedDoc.DocId);
properties.Add("HP", 120);
properties.Add("airbag", true);
carVWdoc.update(properties);

AbtooDocument carForddoc = AbtooDocument.createDocument(dbA, "cars");
properties = new Dictionary<string, object>();
properties.Add("color", colorBlueDoc.DocId);
properties.Add("HP", 160);
properties.Add("airbag", false);
carForddoc.update(properties);

… and launch the following query,

DocumentQuery docquery = DocumentQuery.From(dbA, "cars"); 
List<AbtooDocument> docslist = docquery.ExecuteQuery(); 

Console.WriteLine(docslist.Count); // 2

This is the probably the simplest construction, where you are only interested in to get all the documents of a type without any filter or order. Notice how the result of the Query is 2, because we’ve introduced two documents of type cars in the previous step. Just like if we had executed the following SQL sentence “SELECT * FROM cars”.

But what about if we want to access to “cars” documents having more than 150HP, let’s rewrite the query,

DocumentQuery docquery = DocumentQuery.From(dbA, "cars").
                           Condition("HP", DocumentQuery.OperationType.Gt, 150);
List<AbtooDocument> docslist = docquery.ExecuteQuery();

if (docslist.Count > 0)
{
   Console.WriteLine(docslist[0].getString("color.color")); // Blue
   Console.WriteLine(docslist[0].getInt("HP")); // 160
}

We can add any set of conditions to our query with the Condition method. We’ve to add the property name, the operation type and the comparation value.

There’re multiple comparison types,

• Gt, Greater Than.
• Gte, Greater or Equal Than.
• Lt, Less Than.
• Lte, Less or Equal Than.
• Eq, Equal.
• Neq, Not Equal.

We can also filter by a relational property, as if we were retrieving a property. As an example let’s filter by car’s color property,

DocumentQuery docquery = DocumentQuery.From(dbA, "cars").
                            Condition("color.color", DocumentQuery.OperationType.Eq, "Red");
List<AbtooDocument> docslist = docquery.ExecuteQuery();

if (docslist.Count > 0)
{
   Console.WriteLine(docslist[0].getString("color.color")); // Red
   Console.WriteLine(docslist[0].getInt("color.price")); // 30
   Console.WriteLine(docslist[0].getInt("HP")); // 120
}

We can also mix multiple conditions in a single query, let’s say we want to get the “blue” cars with “HP” greater than 100,

DocumentQuery docquery = DocumentQuery.From(dbA, "cars").
                            Condition("color.color", DocumentQuery.OperationType.Eq, "Blue").
                            AND().
                            Condition("HP", DocumentQuery.OperationType.Gt, 100);

List<AbtooDocument> docslist = docquery.ExecuteQuery();

if (docslist.Count > 0)
{
   Console.WriteLine(docslist[0].getString("color.color")); // Blue
   Console.WriteLine(docslist[0].getInt("color.price")); // 19
   Console.WriteLine(docslist[0].getInt("HP")); // 160
}

There’re also precedence accessors. We can include a parenthesis in order to isolate two or more conditions, let’s say we want the same information than before plus any other cars document with color Red, (Like if we were executed “SELECT * FROM cars WHERE (color = ‘Blue’ AND HP > 100) OR price > 15“)

DocumentQuery docquery = DocumentQuery.From(dbA, "cars").
                         OP().
                            Condition("color.color", DocumentQuery.OperationType.Eq, "Blue").
                            AND().
                            Condition("HP", DocumentQuery.OperationType.Gt, 100).
                         CP().
                         OR().
                         Condition("color.price", DocumentQuery.OperationType.Gt, 15);

List<AbtooDocument> docslist = docquery.ExecuteQuery();

if (docslist.Count > 0)
{
   Console.WriteLine(docslist[0].getString("color.color")); // Red
   Console.WriteLine(docslist[0].getInt("color.price")); // 30
   Console.WriteLine(docslist[0].getInt("HP")); // 120

   Console.WriteLine(docslist[1].getString("color.color")); // Blue
   Console.WriteLine(docslist[1].getInt("color.price")); // 19
   Console.WriteLine(docslist[1].getInt("HP")); // 160
}

Notice how we’re expressing the query in more simple terms, without JOINS, because if we’d have had write the full SQL code with JOINS, we’d have had write something like the following sentence,

SELECT * FROM cars WHERE HP > 100 
   INNER JOIN colors ON colors.id = cars.color AND 
                        colors.color = "Blue" OR
                        colors.price > 15

We can also declare a sentence to retrieve the documents sorted by a particular property, if we’d like to retrieve the same information than the previous example but in this case sorted by descendent “HP”,

DocumentQuery docquery = DocumentQuery.From(dbA, "cars").
                         OP().
                            Condition("color.color", DocumentQuery.OperationType.Eq, "Blue").
                            AND().
                            Condition("HP", DocumentQuery.OperationType.Gt, 100).
                         CP().
                         OR().
                         Condition("color.price", DocumentQuery.OperationType.Gt, 15).
                         OrderBy("HP", true);

List<AbtooDocument> docslist = docquery.ExecuteQuery();

if (docslist.Count > 0)
{
   Console.WriteLine(docslist[0].getString("color.color")); // Blue
   Console.WriteLine(docslist[0].getInt("color.price")); // 19
   Console.WriteLine(docslist[0].getInt("HP")); // 160

   Console.WriteLine(docslist[1].getString("color.color")); // Red
   Console.WriteLine(docslist[1].getInt("color.price")); // 30
   Console.WriteLine(docslist[1].getInt("HP")); // 120
}

As you can see the order of the result is inverted, giving a result sorted by HP descendent, 160 and then 120. The second parameter of the OrderBy method is just to indicate the sense of the order. The default value is false, giving an ascendent order. We can fully omit to put the second parameter if what we want is an ascendent order.

And last but no least, we can also define an offset and a limit for any single query, adding another method to it. This is a very useful feature, mostly used whenever we need to carry on a pagination over the total Documents. That way we can show the full data, page by page.

Applying it over the same query than before but to retrieve just the second document,

DocumentQuery docquery = DocumentQuery.From(dbA, "cars").
                         OP().
                            Condition("color.color", DocumentQuery.OperationType.Eq, "Blue").
                            AND().
                            Condition("HP", DocumentQuery.OperationType.Gt, 100).
                         CP().
                         OR().
                         Condition("color.price", DocumentQuery.OperationType.Gt, 15).
                         OrderBy("HP", false).
                         SkipCount(1, 1);

List<AbtooDocument> docslist = docquery.ExecuteQuery();

if (docslist.Count > 0)
{
   Console.WriteLine(docslist[0].getString("color.color")); // Blue
   Console.WriteLine(docslist[0].getInt("color.price")); // 19
   Console.WriteLine(docslist[0].getInt("HP")); // 160
}

The method SkipCount has two parameters, the first one is used to declare an offset or a number of documents we want to skip from the results, the second parameter is used to fix a limit in how many documents do we want to retrieve from the database as much. With both of them we can declare a pagination easily.

AggregationQuery

We can use AggregationQuery class if what we want is to extract some global information about a subset of documents, for example, following our example, what about if we want to know the maximun HP within all the cars, let’s do it,

AggregationQuery docquery = AggregationQuery.From(dbA, "cars").
                            Select(AggregationQuery.AgregationType.max, "HP");
List<object> results = docquery.ExecuteQuery();

if (results.Count > 0)
{
   Int64? maxhp = results[0] as Int64?;
   Console.WriteLine(maxhp); // 160
}

Notice how the method “Select“ is used in order to retrieve some global information about any single field or a set of fields. You can add as many “Select” as you want, referencing the same field or another one, using the same aggregation type or another one.

At the moment this lines are written, there’re the following Aggregation function types, all of them calculated over a subset of documents that fits the query conditions,

• avg, retrieve the average value.
• count, retrieve the number of documents.
• countDistinct, like count, but it gives only the number of documents that are distinct from each other.
• max, the maximun value for a given field.
• min, the minimun value for a given field.
• sum, the arithmetic sum value of a given field for the whole query documents.

We can define a set of conditions over the query like we’ve done before while we’re talking about DocumentQuery class, as an example we can retrieve the maximun HP from the database only if HP is greater than 100,

AggregationQuery docquery = AggregationQuery.From(dbA, "cars").
                            Select(AggregationQuery.AgregationType.max, "HP").
                            Condition("HP", AggregationQuery.OperationType.Gt, 100);

List<object> results = docquery.ExecuteQuery();

if (results.Count > 0)
{
   Int64? maxhp = results[0] as Int64?;
   Console.WriteLine(maxhp); // 160
}

The result is exactly the same than before, this is just for illustration purpose. As it was done before, we can add logical connectors AND/OR or parenthesis, to be able to define any logic we want for the query conditions.

We can also retrieve information about properties with a relational dependency, for example if we’d like to retrieve the average price of the whole cars, we’d write,

AggregationQuery docquery = AggregationQuery.From(dbA, "cars").
                            Select(AggregationQuery.AgregationType.avg, "color.price");

List<object> results = docquery.ExecuteQuery();

if (results.Count > 0)
{
   Console.WriteLine(results[0]); // 24.5
}

There’re two prices, 30 for Red cars and 19 for blue ones, the arithmetic average is 24.5, so the result is right.

We can even mix properties with a relational dependency into the select and the conditions parts, this way following the previous example, if we’d like to retrieve the average price, but only if prices are gretater than 20, we’d write,

AggregationQuery docquery = AggregationQuery.From(dbA, "cars").
                            Select(AggregationQuery.AgregationType.avg, "color.price").
                            Condition("color.price", AggregationQuery.OperationType.Gt, 20);

List<object> results = docquery.ExecuteQuery();

if (results.Count > 0)
{
   Console.WriteLine(results[0]); // 30
}

This is right due to the fact that there’s only one document that fits the conditions, so the average value is the actual value, in this particular case the value of the Red color document.

Conflicts are one of the center topic about abetooDB. Conflicts are triggered whenever the revision chain is broken and it could happend if more than one writer have created a new revision over the same document,while they are offline, and then they try to syncronize its revision with each other. It could also happend, if within the same database we have two version of the same document.

But first let’s explain how the document revisions chain works in abetooDB.

Whenever a new revision of a document is stored in the database a new revision identifier is created with it. So after several updates have taken place, a revision chain, like the following one, is forming.

In the example above every revision has a two letters identifier, generated randomly. This is just an example for illustration purpose, in reality the abetooDB document revision identifier and its revision identifiers are composed by a larger signature to give a guarantee that there will be no collisions. Every document identifier and revision identifier is unique along, not only the local database, but all the distributed databases.

We can access to any previous revision using the HistoryRevisions document property. Revisions are sorted by order of arrival, most recent first.

How to trigger a conflict?

Let’s trigger a conflict, to do that we have to try to insert a new revision in the document but with an old version of it. Let’s do it against the local database, so first insert a document in the database,

// Instantiate a new database
AbtooDB dbA = AbtooDB.getDB("testconflictsdb");

// Define a conflict resolution function
dbA.OnConflict += ((sender, e) =>
{
   e.winnerrev = null; // pick no one revision as a winner
}); 

// Insert a document
AbtooDocument car = AbtooDocument.createDocument(dbA, "cars");
Dictionary<string, object> properties = new Dictionary<string, object>();
properties.Add("color", "Red");
properties.Add("HP", 120);
properties.Add("airbag", true);
car.update(properties);

So now we have a document with a single revision, the current one,

Now retrieve two references of the document we’ve created above,

// Retrieve two references of the created document
AbtooDocument car1 = AbtooDocument.getDocById(dbA, car.DocId);
AbtooDocument car2 = AbtooDocument.getDocById(dbA, car.DocId);

Update car1 with a new set of properties generating a new revision,

// Update car1 reference with a new revision
properties = new Dictionary<string, object>();
properties.Add("color", "Blue");
properties.Add("HP", 130);
properties.Add("airbag", false);
car1.update(properties);

Updating the document revision chain, what we have is,

Without retrieving again car2 from the database, remember that car2 is referencing to an older revision of the document, let’s update car2 with a new set of properties, this operation will trigger a conflict,

// Update car2 reference with a new revision,
// but car2 is an "old" version => trigger a conflict.
properties = new Dictionary<string, object>();
properties.Add("color", "Orange");
properties.Add("HP", 140);
properties.Add("airbag", true);
car2.update(properties);

The document revisions chain looks like something like this,

We can know if a document has any conflicts with the method hasConflict,

Console.WriteLine(car2.hasConflict()); // true
Console.WriteLine(car2.getString("color")); // Blue

Notice how when we retrieve the current value of the color property we get the Blue value, this is due to the fact that this was the last revision inserted within the database with no conflicts. So the CurrentRevision of the document is referencing to the revision with the RevId: Qc.

But what about if we want to access to the conflicting revision(s) of the document, we can do so by accessing the the ConflictRevisions property of the document,

AbtooRev conflictrevision = car2.ConflictRevisions[0];
Console.WriteLine(conflictrevision.getString("color")); // Orange

So the first item in the collection of the conflicting revisions correspond to the revision with the RevId: eL, with an Orange value for the color property.

The example above was exposed just for illustration purpose, usually conflicts are triggered by sync processes running in the background.

How to solve a conflict?

Notice how at the very beggining of the definition of the database in the example above, we’ve introduced the following lines of code,

AbtooDB dbA = AbtooDB.getDB("testconflictsdb");
// Define a conflict resolution function
dbA.OnConflict += ((sender, e) =>
{
   e.winnerrev = null;
});

As an advance, the meaning of this lines is to let the user solve the conflict later.

abetooDB let’s we solve the conflicts in three different ways. This is up to the developer to define the way that fits better for his application.

But there is a very important question, due to the fact that abetooDB is a distributed database, whenever we define a conflict resolution function, it has to be consistent along the whole databases. All of them have to do exactly the same withouth need to interchange any message with each other. The conflict resolution function has to generate exactly the same result for a set of input revisions along the whole databases.

Automatic conflict resolution

If we don’t define any conflict resolution function, like it was done before, abetooDB will solve any conflict for us automatically. And It will do it picking the revision with the larger timestamp as the winner one. So if we replicate the example above with no conflict resolution function, the conflict will appear, but it will be automatically solved by abetooDB.

// Instantiate a new database
// No conflict resolution function
AbtooDB dbA = AbtooDB.getDB("testconflictsdb");

// Insert a document
AbtooDocument car = AbtooDocument.createDocument(dbA, "cars");
Dictionary<string, object> properties = new Dictionary<string, object>();
properties.Add("color", "Red");
properties.Add("HP", 120);
properties.Add("airbag", true);
car.update(properties);

// Retrieve two references of the created document
AbtooDocument car1 = AbtooDocument.getDocById(dbA, car.DocId);
AbtooDocument car2 = AbtooDocument.getDocById(dbA, car.DocId);

// Update car1 reference with a new revision
properties = new Dictionary<string, object>();
properties.Add("color", "Blue");
properties.Add("HP", 130);
properties.Add("airbag", false);
car1.update(properties);

// Update car2 reference with a new revision,
// but car2 is an "old" version => trigger a conflict.
// but is solved by abetooDB
properties = new Dictionary<string, object>();
properties.Add("color", "Orange");
properties.Add("HP", 140);
properties.Add("airbag", true);
car2.update(properties);

Console.WriteLine(car2.hasConflict()); // false
Console.WriteLine(car2.getString("color")); // Orange

Notice how now the code is exactly the same but without any conflict resolution function. Conflict is triggered and solved internally, the last inserted revision is picked as the winner one.

This functionality could be very usefull if we are working with time based revisions, and what we want is to solve any conflict getting the last revision generated as the winner one. Notice that abetooDB pick the revision with the larger timestamp as the winner one, not the last inserted. This could be very important in a distributed enviroment.

Picking the winner revision manually, whenever a conflict occur

This is a very useful feature that lets the developer take a full control about the question of what revision have to be taken as the winner one, for every single situation.

Maybe if we have different types of documents like cars, colors, etc, like it was exposed in some previous examples, we could be interested into apply some conflict resolution algorithm over one type, different from the others.

Let’s rewrite the example above but this time picking the current revision as the winner one,

// Instantiate a new database
// Define a conflict resolution function
// that picks the current revision as the winner one
AbtooDB dbA = AbtooDB.getDB("testconflictsdb");
dbA.OnConflict += ((sender, revisionslist) =>
{
   AbtooRev currentrev = revisionslist.confictsrevs[0];
   revisionslist.winnerrev = currentrev;
});

// Insert a document
AbtooDocument car = AbtooDocument.createDocument(dbA, "cars");
Dictionary<string, object> properties = new Dictionary<string, object>();
properties.Add("color", "Red");
properties.Add("HP", 120);
properties.Add("airbag", true);
car.update(properties);

// Retrieve two references of the created document
AbtooDocument car1 = AbtooDocument.getDocById(dbA, car.DocId);
AbtooDocument car2 = AbtooDocument.getDocById(dbA, car.DocId);

// Update car1 reference with a new revision
properties = new Dictionary<string, object>();
properties.Add("color", "Blue");
properties.Add("HP", 130);
properties.Add("airbag", false);
car1.update(properties);

// Update car2 reference with a new revision,
// but car2 is an "old" version => trigger a conflict.
// but is solved by the current resolution function
properties = new Dictionary<string, object>();
properties.Add("color", "Orange");
properties.Add("HP", 140);
properties.Add("airbag", true);
car2.update(properties);

Console.WriteLine(car2.hasConflict()); // false
Console.WriteLine(car2.getString("color")); // Blue

Notice how now despite of we’ve inserted the Orange revision triggering a conflict, the conflict resolution function picks the first revision as the winner one, which is the current revision, the last valid one.

Picking the winner revision manually, but with the participation of the end user

What about if at the moment the conflict take place we cannot pick any revision as a winner because we cannot define a fixed resolution algorithm for every single situation. This is a very interesting feature, mostly used whenever we need the participation of the final user in order to solve the conflict.

Imagine that we have two different revisions of the same document in conflict, and the conflict is related to some kind of information understandable only by the end user. Following the previous examples, let’s create a new conflict,

// Instantiate a new database
// Define a conflict resolution function
AbtooDB dbA = AbtooDB.getDB("testconflictsdb");
dbA.OnConflict += ((sender, e) =>
{
   if (e.doc.DocType == "cars")
   {
      e.winnerrev = null; // let the user decide
   }
   else
   {
      e.winnerrev = e.confictsrevs[0];
   }
});

// Insert a document
AbtooDocument car = AbtooDocument.createDocument(dbA, "cars");
Dictionary<string, object> properties = new Dictionary<string, object>();
properties.Add("color", "Red");
properties.Add("HP", 120);
properties.Add("airbag", true);
car.update(properties);

// Retrieve two references of the created document
AbtooDocument car1 = AbtooDocument.getDocById(dbA, car.DocId);
AbtooDocument car2 = AbtooDocument.getDocById(dbA, car.DocId);

// Update car1 reference with a new revision
properties = new Dictionary<string, object>();
properties.Add("color", "Red");
properties.Add("HP", 130);
properties.Add("airbag", false);
car1.update(properties);

// Update car2 reference with a new revision,
// but car2 is an "old" version => trigger a conflict.
properties = new Dictionary<string, object>();
properties.Add("color", "Red");
properties.Add("HP", 140);
properties.Add("airbag", false);
car2.update(properties);

// Check, conflict is triggered
Console.WriteLine(car2.hasConflict()); // true

Now we have a document with two different revisions in conflict, one with HP 130 and other with HP 140. We cannot pick any of these revisions as a winner one automatically, because we don’t have a meaningful way to know which one is the right one. We need the participation of the end user, maybe showing these conflict revisions in a GUI and letting the user pick one of them for us.

// let the user decide which revision is the right one
// ...
// Show revisions in a GUI and let the user pick one
// ...
// ...
// user gets the current revision as the right one
AbtooRev winrev = car2.CurrentRevision;

Once we have a valid revision and we want to persist it into the database to solve the conflict, we can call the method solveConflict, with just a single parameter, the revision we want to be the current one.

// Solve conflict
car2.solveConflict(winrev);

And now if we test again to know if there are any conflict within the document, we get,

// Check, conflict is triggered
Console.WriteLine(car2.hasConflict()); // false
Console.WriteLine(car2.getInt("HP")); // 130

So the conflict is gone.

But what about if what we want is not to pick an existing revision, but to create a new one merging properties of two or more revisions.

Following the example above but unlike to select a revision between the existing ones. Now let’s create another new revision with a new set of properties,

// let the user decide which revision is the right one
// ...
// Show revisions in a GUI
// ...
// ...
// user sets the arithmetic average as the right HP value
properties = new Dictionary<string, object>();
properties.Add("color", "Red");
properties.Add("HP", 135);
properties.Add("airbag", false);
AbtooRev winrev = dbA.createRevision(properties);

// Solve conflict
car2.solveConflict(winrev);
 
// Check, conflict is triggered
Console.WriteLine(car2.hasConflict()); // false
Console.WriteLine(car2.getInt("HP")); // 135

How to know if there are any document with conflicts?

We can retrieve the collection of documents with conflitc(s) at any given time by calling the getConflictDocs method this way,

List<AbtooDocument> conflictdocs = dbA.getConflitcDocs();

Then we can iterate over the collection solving the conflicts as it was described before.

The synchronization capability of abetooDB is one of the key aspects that makes the database more than the sum of the parts. It makes the development process of distributed applications an extremely simple task. It works like an abstraction layer freeing the developers from deal with the underlying low level communication and  synchronization details.

Despite of abetooDB is a distributed database, this doesn’t means that all the individual databases have the same information and every single changed made in one of them is blindly synchronized with the rest. Unlike this, we only sync with the world the subset of documents we want to share. This way we can work with our locally generated documents, and sync only a particular subset of these documents against one database, an another subset of documents against another database and so on.

This way we get the best of the two worlds (Distributed vs Not Distributed databases). All Documents that are locally needed are, in fact, locally available, so the amount of time to access to this data is drastically reduced. We are also saving space, because data are only where they’re needed.

In order to uniquely identify a database against the rest, we’re going to need a Channel Identifier. This channel identifer is unique along the whole databases, it includes a SHA-512 digital signature that protects it from third parties unauthorized access. Only the owner of a channel id knows it. In the Channel ID lesson, we’re going to explain How to obtain some free Channel IDs and we’re going to talk about it deeper. So far, what we need to know is that to send/receive sync data to/from other databases, we need a Channel Id.

How to Sync a database with another one?

Let’s go step by step discovering all the abetooDB sync features. The following examples will use more than one local database, in the same source code, just for illustration purpose, in a regular situation the databases will be splited, one by device.

First let’s build a very basic example, just define a database and declare a sync listener over it to attend remote sync requests,

//Channel Id
string ch1 = "-znkDIDR3KEib6KVa3t-afg636368895046700582#6d72576b70073b56b4d40b43a66096f13e65e0c0aa61dda7b63bd3fe3a86eda755f4fcbc7af8b6fea319291245d84b02c1e46d602556e55cda6d9dc48a3febc6";

// Instantiate a new database
AbtooDB dbA = AbtooDB.getDB("testsyncdb1");

// Define a Replica Listener
ReplicaListener replicalistenerdbA = new ReplicaListener(dbA, ch1);
replicalistenerdbA.start();

Let’s define another database with a change listener, and again a sync listener to attend remote sync requests,

//Channel Id
string ch2 = "-5Qd1Xtbr7UyBMzLQjUB2cg636368896279820402#fe315ec96b0945b54ef5eab6c986830917519e00cef7aefef2bb7368cffc776a38b7f2d3a72722d820811d0872c1f7d8972d0eb6eb4bf2423cd5cc8a34e6b5e9";

// Instantiate another database
AbtooDB dbB = AbtooDB.getDB("testsyncdb2");
dbB.OnChange += ((sender, docs) =>
{
   foreach (var doc in docs)
   {
      Console.WriteLine("dbB change:" + doc.getInt("HP"));
   }
});
// Define a Replica Listener
ReplicaListener replicalistenerdbB = new ReplicaListener(dbB, ch2);
replicalistenerdbB.start();

So far, we have two databases, both of them listening for incoming sync requests. Let’s declare a sync action from dbA to dbB, so whenever a new document is updated within dbA, this update will be automagically synced to dbB,

ReplicaSync replicasyncdbA1 = replicalistenerdbA.CreateReplicaSync(ch2);
replicasyncdbA1.startSync();

Notice how we only have to call to CreateReplicaSync method with the target Channel Id as the parameter, and then start it. In this particular case ch2 is the Channel Id of the dbB database.

Schematically we have,

We only have to insert a new document in dbA, and all the magic will take place. Since we’ve defined a change listener in dbB, whenever this document is synced a new line will appear in the console,

AbtooDocument car = AbtooDocument.createDocument(dbA, "cars");
Dictionary<string, object> properties = new Dictionary<string, object>();
properties.Add("color", "Red");
properties.Add("HP", 45);
properties.Add("airbag", true);
car.update(properties);

… and if we launch the whole code, we’ll get the following response in the console,

dbB change:45

What about if we want to sync just a subset of documents?

If we want to define a rule to sync only a subset of documents, we can declare a Filter. Using a Filter we can define an algorithm, as complex as we want and using all the C# language capabilities, to pick just the subset of documents we are interested in.

Let’s modify the example above to introduce a Filter in the ReplicaSync dbA->dbB.

ReplicaSync replicasyncdbA1 = replicalistenerdbA.CreateReplicaSync(ch2);
replicasyncdbA1.Filter += ((sender, replicaDocument) =>
{
   string type = replicaDocument.document.DocType;
   Int64? hp = replicaDocument.document.getInt("HP");

   if (type == "cars" && hp > 50)
   {
      replicaDocument.replicate = true;
   }
   else
   {
      replicaDocument.replicate = false;
   }
});
replicasyncdbA1.startSync();

What we want to achieve is to sync documents of type cars and with a HP greater than 50. Notice that the important aspect within the Filter algorithm is to define a value for the replicate attribute, for every single situation we want. This attribute come with a default value of true, so the default behaviour is to sync everything.

If we now try to update a Document with HP less than 50, this change won’t be synced.

AbtooDocument car = AbtooDocument.createDocument(dbA, "cars");
Dictionary<string, object> properties = new Dictionary<string, object>();
properties.Add("color", "Red");
properties.Add("HP", 45);
properties.Add("airbag", true);
car.update(properties);

A document of type colors won’t be synced,

AbtooDocument colorRedDoc = AbtooDocument.createDocument(dbA, "colors");
Dictionary<string, object> properties = new Dictionary<string, object>();
properties.Add("color", "Red");
properties.Add("price", 30);
properties.Add("available", true);
colorRedDoc.update(properties);

But now if we try to insert a cars document with HP 60.

AbtooDocument car1 = AbtooDocument.createDocument(dbA, "cars");
properties = new Dictionary<string, object>();
properties.Add("color", "Red");
properties.Add("HP", 60);
properties.Add("airbag", true);
car1.update(properties);

… the document is synced,

dbB change:60

Is There a way to stop and relaunch a sync?

Sure, you can stop any local ReplicaListener object and any or all of the associated ReplicaSync’s objects declared. But you have to take into account that a ReplicaSync object depends on its associated ReplicaListener, which means that, if we stop a ReplicaListener object , all the associated ReplicaSync’s will be stopped.

Let’s explain this topic with an example, we’re going to declare a database with a ReplicaListener to attend remote sync requests,

// Database
AbtooDB dbA = AbtooDB.getDB("testsyncdb1");
 
// Define a Replica Listener
ReplicaListener replicalistenerdbA = new ReplicaListener(dbA, ch1);
replicalistenerdbA.start();

And now we’re going to declare two ReplicaSync objects to track and sync any change within dbA,

string ch2 = "-5Qd1Xtbr7UyBMzLQjUB2cg636368896279820402#fe315ec96b0945b54ef5eab6c986830917519e00cef7aefef2bb7368cffc776a38b7f2d3a72722d820811d0872c1f7d8972d0eb6eb4bf2423cd5cc8a34e6b5e9";
string ch3 = "-AbaWBBELp0WxsC47_rdsjA636369480139438627#cf8790e3aff8718f7518e2c069685fbd3e665a27562f09964a8ed7728cf1946be6fda54247b3daffc7e87d854b27273ab642bd7e9431cb1974e290a26093ae54";

ReplicaSync replicasyncdbA1 = replicalistenerdbA.CreateReplicaSync(ch2);
ReplicaSync replicasyncdbA2 = replicalistenerdbA.CreateReplicaSync(ch3);

We can access to a ReplicaSync status this way,

bool isSync1 = replicasyncdbA1.isSyncing(); // true
bool isSync2 = replicasyncdbA2.isSyncing(); // true

And we can stop the sync process just calling stopSync this way,

replicasyncdbA1.stopSync();

On the other hand, if what we want is to stop the ReplicaListener object, we can do so this way,

replicalistenerdbA.stop();

… but notice that once a ReplicaListener object is stopped, all of the associated ReplicaSync objects will stop syncing til ReplicaListener is started again, this is due to the fact that a ReplicaListener defines not only a path to receive remote sync requests, but also a path to receive sync acknowledges.

You can use abetooDB for free, even in a commercial product. abetooDB is distributed under The MIT license, It means that you can do virtually what you want with abetooDB.

MIT License

Copyright 2017 Chocron J.

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

In order to send you a new Channel ID, please enter your e-mail,