skip to content
Relatively General .NET

Modeling Relationships in a DDD Way

by Vladimir Khorikov

posted on: April 19, 2022

Let’s talk about modeling of relationships, including the dreaded many-to-many relationships, in a DDD way.

RavenDB with the Java API

by Oren Eini

posted on: April 19, 2022

I usually talk about RavenDB in the context of C# and .NET, but we also have clients for many other platforms. On Thursday, the Copenhagen Javagruppen Meetup is doing an online event to show how you can use RavenDB from Java. The meetup is open to the public, and we would love to see you there.

How to list all routes in an ASP.NET Core application

by Gérald Barré

posted on: April 18, 2022

When your ASP.NET Core application is big enough, you may want to have a comprehensive view of all routes. There are multiple ways to declare routes. You can use Minimal API, Controllers, Razor Pages, gRPC, Health checks, etc. But all of them use the same routing system under the hood.The collectio

Recording

by Oren Eini

posted on: April 11, 2022

Last week I did a webinar about Clean Architecture, and it run about twice as long as I expected it to be. Mostly because I got some really interesting questions and I think we had a great discussion.You can watch all of it here, as usual, comments are very welcome:

Uploading multiple files using InputFile in Blazor

by Gérald Barré

posted on: April 11, 2022

Blazor provides a component to upload files. You can use the <InputFile> component and its OnChange event to get the selected files. It works well for single-file uploads. But, if the user selects new files while the first files are still uploading, you may get an error. You can reproduce thi

Surprising behavior when roundtripping JSON documents

by Oren Eini

posted on: April 08, 2022

We run into a really interesting bug. For some reason, the system was behaving in a totally unexpected manner for some parts of the data. For pretty much the same input, we would get the wrong result, and we couldn’t figure out why. Here is our source data: This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters Show hidden characters { "Server": "PRD-392", "CpuLoad": { "2": "94%", "1": "49%", "0": "32%", "3": "10%" } } view raw metrics.json hosted with ❤ by GitHub This is some metrics data about servers, and you’ll note that we report the CPU load for each core on the instance and that the results are sorted based on the actual load. Here is what this looks like, the image on the left is wrong while the image on the right is right (pun intended). Why do we have this behavior? Well, let’s look at the actual data, shall we? They are… the same. Exactly the same, in fact. We can throw that into diff engine and they will tell me that they are identical (except for the document id). What is going on here? Well, here is the issue, what you see is not what you get. Look at the JSON text that I have above, and compare that to the documents we see in the images. RavenDB shows the documents in a nicely formatted manner, and along the way, it messed up something pretty important. In our case, we used an object to hold the various details about the instances. And we relied that the insertion sort order for the properties would stay the same when reading the document. That is actually the case, and RavenDB goes to great lengths to ensure that this is the case. However… In order to prettify the document, we call to JSON.parse() and JSON.stringify() (on the client side), which give us nicely formatted output. Along the way, however, we run into JavaScript and its “ideas” about how things should work. In particular, JavaScript threats properties whose key is a number in a different way than other values. All the numeric properties will be sorted according to their integer value, while non numeric values will be sorted using insertion order. That only applies to documents that were modified in the studio, however. The RavenDB server and client API are keeping the properties in insertion order. Only if you modified the document using the Studio will you get this. But because we always show the documents in the same manner, it was invisible to us for a long while. For that matter, it took an embarrassingly long time of debugging this problem, because (naturally) whenever we viewed the data, we did that with formatting, which meant that we never actually saw the differences between the raw versions of the documents.