A day in the life of...

I've been developing a chemistry game for learning The Periodic Table. This game features the song The Elements by Tom Lehrer . I've corresponded with Tom a few times via email to seek his permission to use his song / recording in the game. Surprisingly though, the discussion led to something quite unexpected. Whilst discussing the elements discovered since he wrote his song I proposed a specific arrangement for including them into the song. Tom said that for many decades he has been uninterested in adding the elements, and that all proposals to date "do not scan or rhyme". Apparently, mine didn't either, but my version "looks so close to satifactory" that he couldn't resist using it as the basis to completing the song himself.   Here is a screenshot of an email from Mr Lehrer himself.     He doesn't say where to insert the new elements, but my guess would be where he says "I left out one actually" at 55 seconds in his Copenhagen re...

The application I am currently working on loads text files, transforms them, and then saves them as relational data. I use Entity Framework Core with SQL Server for my persistence. Unfortunately, when inserting so much data I keep experiencing exceptions because SQL Server is throwing deadlock exceptions and preventing my data from being saved. The insert involves data for 4 related tables, every access to the DB is an insert, which is why I was so surprised to see SQL Server couldn't cope with it - especially as Firebird SQL didn't struggle (nor did PostgreSQL).  It seems that adding OPTION (LOOP JOIN) to the end of SQL Statements prevents this problem, so I wrote an extension to ensure it is appended to Entity Framework Core generated SQL. It is used like so: protected override void OnConfiguring(DbContextOptionsBuilder options) { base.OnConfiguring(options); options.UseLoopJoinQueries(); } and the extension code you need is: public static class UseLoopJoinQueriesExte...

Note: This agorithm was co-authored by Phillipa Berresford. I wanted my domain classes to be able to reference each other by Id without having to add association properties - as I felt having all of this navigation in the model made it messy. I'd much rather have association properties within my aggregates (PurchaseOrder to PurchaseOrderLines) but not elsewhere. This was okay when I needed to add a reference to an object that already existed in the DB, but when I was adding a reference to a new object I needed to know the object's Id before Entity Framework Core saved it to the DB. As my tables were using DB assigned incrementing INT columns this was not possible, so it become obvious I was going to have to switch to GUID Ids. The problem with using GUIDs as clustered primary keys is that GUIDs are designed to be random. Whereas an auto-incrementing INT key will always result in new rows being appended to the end of a table, GUID keys would result in new rows being inserted...

If you want your Blazor component to have its own dependency injection scope, so you can inject new instances of services and have those services disposed of when the component is disposed, then do the following: First, copy and paste the code below into your application.  Then descend your component from ScopedComponentBase . Finally, decorate your dependency properties with [InjectScoped] rather than [Inject] or @inject . For example @inherits ScopedComponentBase @code { [InjectScoped] private WeatherService MyWeatherService { get; set; } } Here is the code you need using Microsoft.AspNetCore.Components; using System; using System.Collections.Concurrent; using System.Collections.Generic; using System.Linq; using System.Reflection; namespace BlazorApp130.Shared { public abstract class ScopedComponentBase : OwningComponentBase<IServiceProvider> { protected override void OnInitialized() { base.OnInitialized(); DependencyInjector.InjectDependenc...