Friday, 16 August 2019

Rebuild vs Reorganize

Rebuild:

An index ‘rebuild’ creates a fresh, sparkling new structure for the index. If the index is disabled, rebuilding brings it back to life. You can apply a new fillfactor when you rebuild an index. If you cancel a rebuild operation midway, it must roll back (and if it’s being done offline, that can take a while).

Reorganize:

This option is more lightweight. It runs through the leaf level of the index, and as it goes it fixes physical ordering of pages and also compacts pages to apply any previously set fillfactor settings. This operation is always online, and if you cancel it then it’s able to just stop where it is (it doesn’t have a giant operation to rollback).

Wednesday, 28 February 2018

python for loop

for loop in python

There are two types of loops in Python, for and while.

The "for" loop
For loops iterate over a given sequence. Here is an example:

primes = [2, 3, 5, 7]
for prime in primes:
    print(prime)


For loops can iterate over a sequence of numbers using the "range" and "xrange" functions. The difference between range and xrange is that the range function returns a new list with numbers of that specified range, whereas xrange returns an iterator, which is more efficient. (Python 3 uses the range function, which acts like xrange). Note that the range function is zero based.

# Prints out 3,4,5
for x in range(3, 6):
    print(x)

Sunday, 25 February 2018

difference between post and put

The HTTP methods POST and PUT aren't the HTTP equivalent of the CRUD's create and update. They both serve a different purpose. It's quite possible, valid and even preferred in some occasions, to use PUT to create resources, or use POST to update resources.

Use PUT when you can update a resource completely through a specific resource. For instance, if you know that an article resides at http://example.org/article/1234, you can PUT a new resource representation of this article directly through a PUT on this URL.

If you do not know the actual resource location, for instance, when you add a new article, but do not have any idea where to store it, you can POSTit to an URL, and let the server decide the actual URL

Wednesday, 29 November 2017

Linq VS stored procedure

1) Stored procedure is a best way for writing complex queries as compared to LINQ.

2) Stored procedures are faster as compared to LINQ query since they have a predictable execution
    plan and can take the full advantage of SQL features.

3) When a stored procedure is being executed next time, the database used the cached execution plan
    to execute that stored procedure.

4) LINQ has full type checking at compile-time and Intellisense support in Visual Studio as compared
    to stored procedure. This powerful feature helps you to avoid run-time errors.

5) LINQ allows debugging through .NET debugger as compared to stored procedure.

6) LINQ also supports various .NET framework features like multi –threading as compared to stored
    procedures.

7) LINQ provides the uniform programming model (means common query syntax) to query the
    multiple databases while you need to re-write the stored procedure for different databases.

8) Deploying LINQ based application is much easy and simple as compared to stored procedures
    based. Since in case of stored procedures, you need to provide a SQL script for deployment but in
    case of LINQ everything gets complied into the DLLs. Hence you need to deploy only DLLs.

9) LINQ query is compiled each and every time while stored procedures re-used the cached
    execution plan to execute. Hence, LINQ query takes more time in execution as compared to stored
     procedures.

10) LINQ is not the good for writing complex queries as compared to stored procedures.

11) LINQ is not a good way for bulk insert and update operations.

12) Performance is degraded if you don't write the LINQ query correctly.

13) If you have done some changes in your query, you have to recompile it and redeploy its DLLs to        the server.

Sunday, 26 November 2017

Select and SelectMany in LINQ


SelectMany: Flattens collections into a single collection (similar to cross join in SQL). It return lists of lists into a single list.

Select: gets a list of lists. So we have to use two nested foreach loops to print the subjects.


// With Select
IEnumerable<IEnumerable<Author>> tmp1 = SampleData.Books.Select(book => book.Authors);
tmp1.Dump("With Select");
foreach (var authors in tmp1)
{
  foreach (var author in authors)
  {
    author.LastName.Dump();
  }
}

// With SelectMany
IEnumerable<Author> tmp2 = SampleData.Books.SelectMany(book => book.Authors);
tmp2.Dump("With SelectMany");
foreach (var author in tmp2)
{
  author.LastName.Dump();
}

var bookAuthors =
  from book in SampleData.Books
  from author in book.Authors
  select author.LastName;

bookAuthors.Dump("With a double from");

Wednesday, 6 September 2017

Asp net core 2 features

Microsoft Asp.net core 2 features


Kestrel Hardening

The Kestrel web server has new features that make it more suitable as an Internet-facing server. We’ve added a number of server constraint configuration options in the KestrelServerOptions class’s new Limits property. You can now add limits for the following:

Maximum client connections
Maximum request body size
Minimum request body data rate


WebListener Rename

The packages Microsoft.AspNetCore.Server.WebListener and Microsoft.Net.Http.Server have been merged into a new package Microsoft.AspNetCore.Server.HttpSys. The namespaces have been updated to match.



.UseHttpSys(options =>
{
    options.Authentication.Schemes = AuthenticationSchemes.None;
    options.Authentication.AllowAnonymous = true;
    options.MaxConnections = 100;
    options.MaxRequestBodySize = 30000000;
    options.UrlPrefixes.Add("http://localhost:5000");
})


Maximum request body size


The default maximum request body size is 30,000,000 bytes, which is approximately 28.6MB.
The recommended way to override the limit in an ASP.NET Core MVC app is to use the RequestSizeLimit attribute on an action method:

[RequestSizeLimit(100000000)]
public IActionResult MyActionMethod()

Configure URLs and ports to listen on

options.UrlPrefixes.Add("http://localhost:5000");




By default ASP.NET Core binds to http://localhost:5000. To configure URL prefixes and ports, you can use the UseUrls extension method, the urls command-line argument, the ASPNETCORE_URLS environment variable, or the UrlPrefixes property on HttpSysOptions. The following code example uses UrlPrefixes


An advantage of UrlPrefixes is that you get an error message immediately if you try to add a prefix that is formatted wrong. An advantage of UseUrls (shared with urls and ASPNETCORE_URLS) is that you can more easily switch between Kestrel and HTTP.sys.
If you use both UseUrls (or urls or ASPNETCORE_URLS) and UrlPrefixes, the settings in UrlPrefixes override the ones in UseUrls. For more information, see Hosting.