Month: September 2014

Kendo Ui Tip 6 : Customized View through Querying Datasource

Creating a customized view is highly desirable in web applications .

Kendo UI too provides a way to query the datasource through query method.

Available operations are paging, sorting, filtering, grouping. If data is not available or remote operations are enabled, data is requested through the transport. Otherwise operations are executed over the available data.

Example :

View from page 2 with 10 results and data sorted by EmployeeID


This is how we can query datasource and can create a customized view.


Kendo Ui Tip 5 : Retrieving Kendo Grid State

In Kendo UI we can retrieve the state of a Kendo grid and can use the same for many purposes like suppose at a point of time you need to cache the state of the grid so that when you come back to the page you can see the grid in exactly the same form in which you left it.

Finding a grid state is quite easy. Once your grid is created create the object of your kendo grid and find the it’s datasource.


From the datasource we can create the grid state like below.
This gridState take accounts of following aspects of the kendo grid:
  • The page size of the grid.
  • The selected page of the grid.
  • The current state of sorting i.e the columns with whom the grid is sorted currently.
  • The current state of grouping i.e the columns with whom the grid is grouped currently.
  • The current state of filtering i.e the columns with whom the grid is filtered currently.
This is how we can retrieve the state of  a kendo grid.

Performance in MongoDB

Performance is a key and very vital feature of an application. Ageing of applications , dataload and high throughput are the factors which effect the performance of an application and can bring it down steeply. In this post we will be discussing the Performance aspect in MongoDB.

Increase in datasets and size of data in the server can bring the performance of an application down because of few factors like increase in query execution time which will directly increase the time for which the server remains busy.

Many times we have heard that MongoDB is faster then relation databases. It’s because of the unique way in which Mongo can store the datasets in different data servers and can effectively query them. Mongo uses Sharding to achieve this.

Sharding :

Database Sharding is a highly scalable approach for improving the throughput and overall performance of high-transaction, large database-centric business applications.

Sharding is a  unique way of horizontal scaling in which we distribute the data over different servers known as shards. Each shard is a single independent database which can be used to store the datasets. The collection of these shards form a logical database. Chunking down big database into small shards will ensure high availability and data consistency.

How It Works :

In MongoDB, to retrieve the whole entity, Mongo instance follow below procedure:

  •  One index lookup on the collection (assuming the entity is fetched by id)
  • Retrieve the contents of one database page (the actual binary json document)

Possible question arise in mind that how do a Mongo Instance knows that which shard out of many will be containing the relevant dataset which contains the information it is looking for.

When the sharding is done and a cluster of shards is created , all the metadata about the distribution of the datasets is stored in Config servers.

So the Mongo Instance also known as Query routers uses the metadata stored in the config servers to target operations to specific shards.


So this is how we handle Scaling in MongoDB.

Benefits :

Through this partitioning there is a ensured enhancement in the usability of RAM.

Horizontal scaling or sharding automatically handles the load balancing between the shards(Will be next thing).

Load Balancing : 

Initially created shards are created with equal sizes but as the chunk size increases there are possibilities of unequal load among shards. May be one shard grows huge in size in comparison to other shards.

This is big problem because if chunk size of a shard increases to a big size then complete concept of sharding will be of no use as only one shard will be getting handling the most execution and others will be relatively free .To overcome such situation MongoDB has a process of  maintaining a balance between shards.

A balancer is a entity of MongoDB which is responsible to maintain the balance between shards by transferring chunks from a crowded shard to a less crowded shard.

Balancer transfers a big chunk from a shard(Origin Shard) to another less crowded or relatively free shard(Destination shard). It transfers the documents of Origin Shard chunk to destination shard chunk. Destination shard takes care of the changes done to the documents and implement them to the documents after the migration is done.

What happens to the mapping ? As i told earlier that the information about the address of a document that a MongoDB instance is looking for is stored in the config servers, Now as and when a chunk gets transferred from one shard to another the routing will go off.

Balancer only handles this situation as well , once the migration is done balancer modifies the Metadata ,related to the location of the chunk ,stored in the config server so that it remains relevant.


This is how the performance is scaled in MongoDB.

Dynamic models inside ng-repeat

In this post we will be exploring dynamic models inside ng-repeat of AngularJS.

We will be creating dynamic models and will try to access them in our controller.

Need : While generating a repetitive HTML markup through ng-repeat ,other then just normal displaying of data sometimes we also need to generate some controls like textboxes , chackboxes etc. We need to have a model which we can bind with these controls for retrieving their value as and when needed in controller.

There are many ways to achieve , we will be doing it through creating a new property in the looping object. So let’s begin.

Scenario : We have a list of developers with every developer having properties like Name, Project Count. We will be generating dynamic textboxes and will bind models to them and will finally try to access their values in the controller.

Generating Dynamic Models:



In the above code you can see other then two properties(Name and ProjectCount) , We are also generating textboxes against every developer.

For these dynamic textboxes when you will look into the ng-model then you will see that it is”developer.mydata” . So basically here we have created one more property(mydata) dynamically in the developer object which will work as model for the corresponding textbox.

Suppose if there are 5 developers means 5 textboxes , every textbox is bound to a unique model which is “mydata” property of that particular developer object to which the textbox belongs.

Accessing the dynamic models:

The dynamic model is now a part of the developer object. So whenever you need to access any particular model you just need to accesss the $scope.developers in the controller and based on some conditions you can easily retrieve the model(i.e textbox value).

If you have a specific set of functionality like there is a button next to every textbox for saving it’s value to the Database or anything you just need to call the ng-click of the button with current developer object in the param and then you can access the “mydata” property which is the textbox value.

Like in above example what i have done is that i need the textbox value as an when the end user move out of the textbox. So for achieving this, using ng-blur I have called a method SaveValue and I am passing the developer object inside it.




Inside SaveValue method we are retrieving the textbox value from it’s model which is present in the passed developer object and then we can use it for any type of user action.

This is not the only way of handling the dynamic models but is surely a very effective one.