In this blog post I explore PostgreSQL range types and how you can use them from Entity Framework Core.
About a month ago, my open-source project EntityFramework.Exceptions failed to build on AppVeyor, the continuous integration service that I have been using for several years.
Consuming a GraphQL api in C# is straightforward with either using HttpClient directly or using a client library such as GraphQL.Client but both suffer from the same problems: The GraphQL queries do not go through any compile-time checking, and any mistake in the query isn’t discovered until you execute the query at runtime. For example, to query SpaceX GraphQL API for all missions where the manufacturer is Orbital ATK you need to run the following query:
LINQPad.QueryPlanVisualizer is a custom visualizer for LINQPad that shows a database query plan inside LINQPad. It also shows missing indexes for the query that you can create directly from LINQPad. Since then, a new major version, LINQPad 6, was released that targets .NET Core 3 and .NET 5 and uses Entity Framework Core (as well as LINQ-to-SQL) for running Linq queries. To support these changes, I have just released a new version of LINQPad.
In the previous article I introduced EntityFramework.Exceptions, a library which simplifies handling exceptions in Entity Framework Core but the library had one important limitation. In order to use it you had to inherit your custom DbContext from ExceptionProcessorContextBase class. This means that if you wanted to use some other base class for your DbContext you were out of luck. The latest version of the library solves this issue by
When using Entity Framework Core for data access all database exceptions are wrapped in DbUpdateException. If you need to know whether the exception was caused by a unique constraint, value being too long or value missing for a required column you need to dig into the concrete DbException subclass instance and check the error number to determine the exact cause.
EntityFramework.Exceptions simplifies this by handling all the database specific details and throwing different exceptions for different cases. All you have to do is
If you are a heavy LINQPad user you have probably wished to be able to see query execution plan details inside LINQPad. Currently the only way to view query execution plan is to switch to SQL tab, click Analyze SQL button and open the query in SQL Server Management Studio. I got tired of clicking all these buttons and decided to write custom visualizer which solves the issue. With LINQPad.QueryPlanVisualizer you can now view query execution plan and missing indexes as well as create those missing indexes without leaving LINQPad.
Some time ago I came across a post where the author wanted to turn on and off num lock, cap lock and scroll lock led light without actually toggling their state. This sounded challenging and impossible but after some googling I found a piece of code in C for achieving exactly what I was looking for. In this post I show how it works and how to port it to C#
This post is part of a series about building a simple mathematical expression evaluator. For previous posts and full source code see Table of Contents.
In previous part we added support for variables but it has a big disadvantage: values of the variables are bound by position and not by name. This means that you should pass values for the variables in the same order as they appear in the expression. For example the following test will fail:
You have probably heard about Reactive Extensions, a library from Microsoft that greatly simplifies working with asynchronous data streams and allows to query them with Linq operators. There are many different scenarios where using rx results in a much more simple and flexible code. This post demonstrates how to use reactive extensions for loading data from database asynchronously in chunks.