Introduction to MongoDB and GrandNode

MongoDB is open source database solution used in GrandNode.

MongoDB have some advantages, that SQL lacks: scalability, open source community and free license.

Because SQL is relational database, and MongoDB is non-relational, a terminology varys in both. In SQL, single Records are stored in Tables whereas in MongoDB, single Objects are stored in Collections. Database consists of many collection, inside which are stored Objects. You can easily read and modify Object’s fields and values inside JSON (easy-to-read plain-text format).

Because GrandNode is developed on nopCommerce,

• anyone who experienced nopCommerce before, will easily adapt to GrandNode database environemnt
• it is possible to migrate data from nopCommerce SQL database to GrandNode MongoDB database. It requires a “GrandNode Feeds” plugin installed for nopCommerce

ID - how Objects are identified?

In SQL IDs were plain numbers. You wouldn’t pull much information from it, only how many records were already created and where particular record is among other records in sequence.

In MongoDB ID is a 24 character long alphanumeric string. Its value is composed out of 4 different environmental variables.

• First, exact time of creating (see picture below),
• Second, machine name (taken from “0x00ffffff & System.Environment.MachineName.GetHashCode()”),
• Third, PID (taken from “System.Diagnostics.Process.Id”),
• Fourth, an incremented number.

You can check a time of creation of particular Object by yourself here: https://steveridout.github.io/mongo-object-time/.
To assume it, it is possible, for given ID, to obtain information of creation time, machine name (server) and even process ID.
Every ID is assigned automatically whenever new object is created by method on picture below.

In MongoDB ID for newly created Object is always unique (equivalent to SQL primary key). However, there is no equivalent for foreign key - IDs between Collections are not tightly coupled. Other IDs are stored as plain string, so whenever ID of referenced Objects changes, the change is not  reflected in a whole database between Collections.

We do not recommend changing values of Objects inside database unless you are sure of what you do. Even non-ID fields can have crucial value that when manually changed, will yield Exceptions.

Different Structure

In SQL a Record was allowed to have only simple types and ID references to other complex types (rule: one complex type, one Table). MongoDB enables possibility to store another complex types and even arrays of simple/complex types inside one Object. In some cases it is better approach, because it may save server resources, since one request can return two or more complex types (or collection of these) at once (in cases when it makes huge sense to return them together, because they are always used together, never separately).

There is no constraint: it is possible to return in single request an humongous Object with many fields of simple/complex types and arrays of these  simple/complex types. Of course, it reality we return rather an Object with array of small (few fields) complex types (like GenericAttribute) that DOES make sense to return in this manner.

On picture below is presented the Customer Object and its “CustomerRoles” array, where are stored “CustomerRole” Objects.

Simmilar approach in SQL requires sperated Tables with stored “CustomerRole” Records.

(Unrelevant fields were dotted.)

Because this is possible, many previously-separated SQL Tables were “injected” into one Collection.

Repository Layer

One of crucial components of GrandNode application is Repository Layer. It serves as mediator between raw database and high-level service.

You can get an Object out of database in three ways, each one serving different tradeoff in terms of convenience of use and possibilities of control.

In normal case, we just get desired Object from Service (which gets it from Repository, and further, from database itself).
Service Layer is most convenient way to get an Object, since it is suited to fit needs of developer -
you can, for example, get only products that have a Discount equal to ID given as argument.

It is however possible to get an Object from Repository, which enables LINQ querying and full CRUD operations, which is already powerful.

In rare cases you need to get an Object straight from database, which enables full possibilities of MongoDb.Driver.

Augmented Features of Major Entities

Every important Entity have augmented functionality, by inheriting abstract classes and interfaces that impose having certain Properties (that are further used in application).

An Entity by inheriting

1.        BaseEntity, receives ability to assign an arbitrary information (in key-value way, for example for Product it may be { “problem” : “lack of vendors” } )
2.        ISlugSupported, receives a friendly name for Search Engine (e.g. "SeName" : "hp-spectre-xt-pro-ultrabook" )
3.        IAclSupported, receives ability to show certain Products, Categories, Manufacturers only for predefined Customer Roles (guests, registered, vips, privileged)
4.        ILocalizedEntity, gives particular Entity correct naming for active language
5.        IStoreMappingSupported, receives ability to show certain Products, Categories, Manufacturers only for predefined Stores