My First Oqtane Module: or, How I Got Migrations Working In Oqtane

I've learned many lessons the past few days. Not the least of which is: don't just stay on the first page of google results, and go ahead and change up those search terms!

My Intentions

So in my quest to understand Oqtane and the short-term goal of porting my FAQ App over to it, I decided to spin up a "quick" module with:

• a counter
• some basic Database handling
• MudBlazor running inside the module
• how routing to an API works in Oqtane with its authentication features
• and (most importantly): understanding how the heck Oqtane works its Multi-Tenancy magic and manages databases using.... sorta EF Core?

MudBlazor was easy: after a few failed attempts and some confusion, I discover that Studio-Elf has templates available in the Marketplace for just that. Score! Now my MudBlazor-powered module looks good! But wait, it's hijacking the Oqtane theme! Do I use custom css-overrides? Will that even work? I want my module to work with Oqtane's theming... aww heck it, I'll deal with it later.

Next Steps

Next up, implement a button and a counter. Simple. Some placeholder text, and it's time to wire up to the Database. But how? First thing's first, let's define our intentions here: I'm going to display two bits of information, but I want them to live in its own special table in the Oqtane database. So let's cook up a Model, Service, Repository, Controller, the usual. I wasn't going to be using the database *yet* and I didn't know what I needed about routing, but I needed that table to exist and Oqtane to know where it goes. So I hard-coded a nonsense-response in the Controller and Repository and off we go.

Add-Migration CreateFAQDataTable

It yells at me. Something about "Multiple DB Contexts." Ok.

Add-Migration CreateFAQDataTable -context TestModuleDBContext

It yells again. "No Database provider has been configured for this DBContext..."

Well crap. What do I do? No matter what I tried (using a design time fudged constructor, injecting fake dependencies, using a DesignTimeFactory) it was always the same error.

I swear, officer, I DO have a DBContext!

Google helped a lot, giving me different creative ways to fail. I gave up for the day: my work day was almost over anyway and I was just stuck. Hours of banging my head against this wall.

And then I found it. I forget exactly what I goggled, but I finally found it: somebody having a similar issue to me on Github, FOUR years ago. And guess who replied? Shaun Walker, the creator and maintainer of Oqtane. I'm paraphrasing, but he roughly said that due to the multi-tenancy model of Oqtane you simply cannot use the Command Line Migration Tools. Like, at all.

Of course! This makes sense. But it took me way too long to figure this out.

Time for a fix!

Time to scaffold some migrations! I know, I'll make a separate project that has the same models and so forth as my module, but hard-code a database connection string, run the migration tools from there, I'll even call it "MigrationMaker" and...

No. Scrap that. I'll just do it by hand. (Eff it, do it live!)

After creating the migration from scratch (well, with a close look at how the Blog module does it) I was set! Only, how do I run it? Oh, Oqtane handles that automagically on install. Well, that was easy. Nice job Shaun.

After that, I took a long look at how the Blog module handles authentication and API routing, made the requisite changes, and found everything worked as intended on nearly my first try.

Nice job, Shaun.

Final Notes

So, I learned a lot about how Oqtane handles databases, I learned the basics of creating migrations by hand, and I learned that EFCore CLI Tools aren't the magic bullet I want them to be. Oqtane's multi-tenancy, multi-database structure doesn't play nice with them. And that's ok, because now I've got a working module. Next step: porting my FAQ App! Stay tuned...