Posted on

How to debug CosmosDB stored procedure easily

CosmosDB stored procedure, written in javascript, sometimes can be difficult to debug. One easy way is to do console log like normal javascript and debug the code with those logs.

Console logs are by default disabled in CosmosDB stored procedures. You have to enable them first before making the request to CosmosDB.


var options = new RequestOptions()
        {
          PartitionKey = new PartitionKey(partitionKey.ToString()),
          EnableScriptLogging = true
        };

StoredProcedureResponse<TValue> result = await 
  clientMgr.DocumentClient.ExecuteStoredProcedureAsync<TValue>(
          clientMgr.GetStoredProcUri(storedProcName),
          options,
          procedureParams);

Here, TValue = your custom response object

You can now access the console log in your stored procedure written in javascript inside StoredProcedureResponse.ScriptLog like this

Console.WriteLine(result.ScriptLog)

Posted on

Add Sql Script through code first migration – Entity Framework

You can add scripts to code first migration.

First, make sure if any existing migration is pending. If so,

-open the package manager console window.

-Select the appropriate project

-Run “update-database” command (without quote)

Now, add the migration you want to put SQL into.

-Run “Add-Migration SQLIntoMigration”  (without quote)

A new MIgration file will be added with an empty body like this:

Now add the below code inside up() method.

Posted on

How to get the description of an enum in C#?

This simple code shows how to get the description of an enum in C#.

A sample enum could be-

public enum Colors{
[Description("Green but not so much!")]
Greenish,
[Description("Sky Blue")]
SkyBlue,
[Description("Blood Red")]
Blood Red
}

This below code gets the description of the enum-

public string GetEnumDescription(object val)
{
return
val.GetType()
.GetMember(val.ToString())
.FirstOrDefault()?.GetCustomAttribute<DescriptionAttribute>(false)?.Description ??
(val.ToString() == "0" ? "" : val.ToString());
}

Posted on

Get display name of an enum in C#

This is a simple code to get the display name of an enum in C#. Sometimes we need a proper name, not the property names of the enum. The code below gives us the display name of an enum in c#.

A sample enum could be like this:


public enum UserType
{
[Display(Name = "Administrator")]
Admin,
[Display(Name = "Compliance Officer")]
Compliance,
[Display(Name = "HR & Accounts")]
Hr
}

To get the display name-


public string GetDisplayName(this object val)
{
return val.GetType().GetMember(val.ToString())
.FirstOrDefault()?.GetCustomAttribute(false)?.Name ??
(val.ToString() == "0" ? "" : val.ToString());
}

It gets the custom attribute- “Display Attribute” to get the display name of the enum.

Posted on

Estimate bugs in SCRUM?

Bug fix in the agile scrum is a buzzing issue to discuss that we all love to avoid. We use tools like JIRA and scrum board to estimate bugs. But do we want to estimate bugs? Do we really need to?

To understand this aspect properly, we will first need to revise the artifacts of SCRUM. SCRUM has sprints. and for each sprint, it has a fixed backlog that the development team commits to. And it is thriving to produce a functional increment of the product in the sprint.

Now, how do the bugs really come? Bugs can come from mainly two scenarios. The development team has completed a story. During the sprint, the team has found a problem with the completed story. As a result, a bug/issue has been raised. In this context, do we really need to estimate bugs? The more important question would be, when do we actually estimate it? As there is a bug, it means the functionality that the team has produced is not done. So the story cannot be done/completed. Until all the issues related to the story is done away, the story remains open, even if the sprint reaches its end. At this point, the sprint goal won’t be achieved and the PBI (Product Backlog Item) item number will not decrease.

The other scenario- the team hasn’t found any issue during the sprint and the story was completed during one of the previous sprints. Now during the ongoing sprint, the team has found some issues. So how do we really handle this? Sprint backlog cannot be changed as PBI tracking will not be accurate. So the issue can not be handled in this sprint. So we put it in the next sprint.

During the next sprint’s planning meeting, will the team give any estimation? For any kind of estimation to be done for the backlog items, we know that the team has to analyze the stories, understand the problem they are solving, and then plan how many stories they want to do this sprint. But for a bug to be estimated, the team needs to analyze the bug first to understand what is causing the bug to be produced in the first place!

Estimating bugs takes a lot of time (not in all but a lot of cases). When we have investigated a bug enough to make a proper estimation, we could have also fixed that bug at that time.

Now we might say that there are some bugs that we easily know how much time it will take to solve. For defects like these, what we can do is that we can allocate a chunk of time from the sprint to solve as many bugs the team can solve. And this could be at the beginning of the sprint. Jeff Sutherland uses at PatientKeeper half a day of the sprint to solve the bugs remaining from the previous sprint. There is a healthy discussion on stackoverflow on estimating the bugs.
But most importantly, we need to ask the question- if there is something so trivial is left behind, are we really following scrum properly? Are we really delivering functional product increment at the end of the sprint? If our retrospective is being done properly, we would be coming with these answers very early in the sprint. Only then we would be able to save time to implement functionality rather than wasting time to estimate bugs that are not even properly analyzed.

What about the production bugs or critical bugs that come from the end users? If we are following SCRUM as we should be, we will be delivering functional products and the probability of finding this kind of issues is very rare. And when we find this kind of blocking issues, this needs to be handled outside of the scrum team. You can not add a new item to the backlog, so how do you handle it? What if you only have only one scrum team and it needs to be handled right away. In that case, we can assign one or some team members, who have the profound knowledge of the item that is associated with and get it done in a separate branch -preferably as a hotfix. Or after discussing among the scrum team members, keeping in mind about the severity of the issue, the product owner can cancel the sprint for bug fix. But this has to be one of a kind exception, not as a process. They should also keep this item to be discussed in the retrospective. And in the retrospective, it should come out how it came alive in the first place and what needs to be done to avoid it in the future.

Scrum asks are we adding value to what we are doing? More often bugs occur because of technical debts, and as a result, does not bring new business value (it shouldn’t exist in the first place!), so why waste time on estimating something that doesn’t bring value to the customers? It should just be a part of the velocity, so time-boxing to reduce the waste of additional estimations is actually a good idea.

Timeboxing:
For a bug that needs to be analyzed, assign a random hour to investigate and solve that. If the team is able to fix that inside that timebox, it’s all good. But if it’s not possible then the team needs to discuss this issue according to scrum guide.
-No changes are made at this point that endangers the sprint goal set at the beginning of the sprint.
-The scope can be renegotiated between the product owner and the development team, that means escalating the issue as soon as possible.

In the end, SCRUM is all about adding value to the customers. The time spent to estimate bugs adds less value to the customer. It would have been better spent that time on creating a functional product by adhering to the scrum principles from the very beginning. When we focus more on estimating something like bugs, we are forgetting about the core of agile – Individuals and interactions over processes and tools. Just because estimating is available in issue tracking tools like JIRA and TFS, you don’t have to use that. Estimating bugs and taking that into process violates the very core agile is formed on.

If you have liked what I said here or disagreed with the article please leave a comment so that we can have a healthy discussion. And if you want to know more about SCRUM, please download and read the free SCRUM book.

Posted on

Entity Framework Bulk Update

We often need to update items in bulk while working with Entity Framework. As good as it is, entity framework has its quirks like any other ORM tools. Entity Framework bulk update is needed only when you need to update multiple items at a go.

We used classic ADO.NET stored procedure for our long-running processes. But when updating multiple items from models at once we found it rather a tedious process to maintain. We were already using the entity framework in our project for data access along with the classic ADO.NET. So decided to use entity framework for bulk update operations.

In this very short article, I am showing a way how we have updated our list of objects using entity framework DB first. Here we want to update some particular property of a list into our database.

ItemObject = Object model from database
list = the list of items we want to update
ContextFactory.GetContext() = A factory method to get a particular context. This is our application specific method.

Here we updated just a few properties in our model. If we want entity framework to update the whole model we need to set the entity state property to modified for the whole entity.

After the loop is finished, save the context. The data will be updated in the database.

Entity framework bulk update or insert operation is slow. I’d recommend any other option if we can find to do such bulk updates. But in terms of code maintenance, we found it feasible in our case. Be sure to use it when you need this kind of operation.

I hope this helps you guys. If you have any suggestion regarding anything or how should I improve please don’t forget to knock. I’d really appreciate your feedback.

Posted on

Unable to load the specified metadata resource – Entity Framework

We got this issue when we were calling the EDMX file from our DataAccess project. We used entity framework database first approach.

Our EDMX file lied in another project and the DataAccess project was used to do various operations on the EDMX file. But we forgot to add the connection string to the corresponding EDMX file into our DataAccess Project. Hence, this very ambiguous message :

[code language=”csharp”]"Unable to load the specified metadata resource" [/code]

The reason is Res://*/ is a URI which points to resources in the CURRENT assembly. If the Edm is defined in a different assembly from the code which is using it, res://*/ is not going to work because the resource cannot be found. So we need to add the connection string to all the projects that it’s being used in.
So I decided to dig a bit more and found out some possible reasons for this exception in entity framework including ours:

  • The EDMX resides in a separate project. We have to maintain connection string in both the projects. (This is our problem)
  • The MetadataArtifactProcessing property of the model You may have been changed to Copy to Output Directory.
  • There might be a post-compile task to embed the EDMX in the assembly and it’s giving errors for some reason.
  • The connection string itself is wrong. Yes I know it’s a very small thing, but it happens a lot.

 

Posted on

The mapping of CLR type to EDM type is ambiguous because multiple CLR types match the EDM type

This error occurred in our application with a particular case when we stored two procedures with the same name in two different databases. These databases were internally related. We used Entity Framework database first approach for our application.

As EF uses only class names to identify the type mapped in EDMX (namespaces are ignored) – it is a convention to allow mapping classes from different namespaces to a single model, the EDMX could not differentiate the two classes generated from the stored procedures. So it threw this particular error-

[code language=”xml”]
The mapping of CLR type to EDM type is ambiguous because multiple CLR types match the EDM type
[/code]

So the solution is:

  • Don’t use classes with the same unqualified name.
  • Name your stored procedures differently even if they’re in separate databases if you’re planning to use them in a single BLL.
Posted on

Authentication in Module vs MessageHandler

We are often confused about where to put our authentication code in the Asp.Net life cycle’s pipeline. I believe the below discussion can come to help in that regard.

Modules vs MessageHandler:  We can use HTTP message handler to handle our authentication logic. In this case, the message handler examines the HTTP requests and sets the principal. But there are some trade-offs you want to consider before doing that.

  • An HTTP module sees all the requests that go through the ASP.NET pipeline, a message handler sees only the requests that are bound to the web API.
  • We can set authentication logic for each routes using message handlers
  • HTTP modules only work with IIS, so it can only be used for web hosting. Message handler doesn’t depend on IIS. Authentication using message handler can be used for both web hosting and self-hosting.
  • HTTP modules are used for IIS logging, auditing etc
  • HTTP modules run very early in the ASP.NET pipeline. On the other hand, if the principal is set using the message handler, then it only runs when that message handler runs and the principal’s value gets reset when response leaves the message handler.

Usually, if self-hosting is not needed, HTTP module is the correct place to put authentication code. And if we need self-hosting, we need message handlers to handle authentication logics.

Posted on

Authentication basics in ASP.Net

Authentication: Is the process that makes it known about the identity of the user. When a user logs in with his username, password, the server identifies the user based on that.

Creating the principal:

  • Authentication happens in the host. EX: IIS. IIS uses HTTP modules for authentication.
  • Modules can be built in or custom.
  • The host authenticates the user by creating a Principal, It is an IPrincipal object. It represents the security context under which the code is running.
  • Host attaches this newly created principal to the current thread. As we know whenever a request comes to the web server it creates a separate thread for that request to be handled. (Huge discussion). It does so by setting the Thread.CurrentPrincipal.
  • Each principal contains an object called Identity that contains information about the user.
  • If the user is authenticated the identity.isAuthenticated property returns true. For anonymous requests, it returns false.

Setting the principal:

  • For custom authentication: We need to set the principal in two places.
    • Thread.CurrentPrincipal
    • HttpContext.Current.User

Code:

[sourcecode language=”csharp”]

Private void SetPrincipal(IPrincipal Principal)

{

       Thread.CurrentPrincipal = principal;

       if(HttpContext.Current.User != null)

        {

            HttpContext.Current.User = principal;

        }

}

[/sourcecode]

  • For web hosting we need to set these both. For self hosting the HttpContext.Current.User is null.

Modules vs MessageHandler:  We can use HTTP message handler to handle our authentication logic. In this case, the message handler examines the HTTP requests and sets the principal. But there are some trade-offs you want to consider before doing that.

  • An HTTP module sees all the requests that go through the ASP.NET pipeline, a message handler sees only the requests that are bound to the web API.
  • We can set authentication logic for each routes using message handlers
  • HTTP modules only work with IIS, so it can only be used for web hosting. Message handler doesn’t depend on IIS. Authentication using message handler can be used for both web hosting and self-hosting.
  • HTTP modules are used for IIS logging, auditing etc
  • HTTP modules run very early in the ASP.NET pipeline. On the other hand, if the principal is set using the message handler, then it only runs when that message handler runs and the principal’s value gets reset when response leaves the message handler.

Usually, if self-hosting is not needed, HTTP module is the correct place to put authentication code. And if we need self-hosting, we need message handlers to handle authentication logics.