SQL

If you’re new to Docker, it’s hard figuring out even what to search for, and how the concepts tie together, let alone what to pay attention to for your use case.

To make things more difficult, there has been a lot of change over time, and stuff that was once recommended is now not recommended. For example, a lot of older video tutorials recommend using container links which have since been deprecated in favor of user-defined bridge networks .. in case you’re unfamiliar with this, I’ll cover what this means, and why you’d use it later in the blog post.

Once you learn the basics, using Docker in practice is fairly straightforward, and if you’re using Docker at home or at work, the time you spend learning now will save you a massive amount of time and effort in the future.

If you’ve used Docker a bit, are familiar with some of the concepts, how dabbled here and there, but sometimes struggle with connecting some of the concepts, or how to get things set up end-to-end, then this blog post is for you.

In this blog post, I’ll guide you through step by step on:

• The distinction between docker image and containers
• Best practices on how to persist data within containers, and how to control where data is persisted
• How to continue developing on your local machine as usual, while your app is running within a docker container on your local machine
• How to connect your containerised web app to a containerised Microsoft SQL Server

When you are maintaining multiple web apps across environments it can be difficult to keep track of which scripts need to be run to upgrade the database when it comes time to deploy. If you’re maintaining different versions of web apps across environments when the versions can sometimes be significantly out of sync, the difficulty of determining which update scripts need to be run on deployment can explode.

While there are a ton of approaches to keeping your database under version control, if you want something simple and effective that you can implement with minimal time and effort, consider a DatabaseVersionHistory table in your database.

A database version history table will allow you to see at a glance the state the database is in and by comparing it with the update scripts in source control, you will quickly be able to determine which update scripts need to be run.

If you are connecting to a SQL server with the SQL profiler and none of your templates are showing up, compare the versions of the SQL profiler you are running and the version of SQL server that you’re connecting to; there is likely a version mismatch.

If this is the case, what’s likely happening here is that you’re connecting to a SQL 10.50 instance with a SQL 10.0 profiler and the profile templates for 10.50 aren’t present.

In our project, we’re sub classing multiple domain classes from a single Reference Data table – i.e. Volume and Weight types. Among other things, the reference data table contains discriminator, code and value columns. The ‘discriminator’ column stores the name of the class and is used by Fluent NHibernate to determine which subclass to instantiate, the ‘value’ column is the full name of the reference data item, and the ‘code’ column is the abbreviated version of the value.