Override Database Functionality

[magiccodingman]

The override functionality to utilize string based names for database creations has been reported not functional. I'm looking into it.

[c-emin]

Have you had a chance to look into this?

[magiccodingman]

Have you had a chance to look into this?

Not yet. I've been incredibly busy with my business. I'm still in the early stages, so I work insane hours for very little money lol. So, I'm fighting for survival and my free time comes in waves. But I was planning to spend some time on this project this weekend :D

[magiccodingman]

@c-emin So I finally had time to look into this. And I now see why it's disabled. How the current system works is it deploys known schema's. And after digging into this, I found my own notes on the subject that I had forgotten about. Here's the TLDR. I disabled this feature until the new migration system is created. This is because the current deployment system of how schema's are deployed is temporary.

Right now it's a modified version of the original fork from nwestfall but I don't really call this much of a fork anymore as there's not really much to any surviving parts of the code. I think this is the last aspect that's in spirit kind of like the old system.

But right now the app just auto deploys databases and tables that it's aware of instead of handling things dynamically in the way it's no built for but not fully utilizing until the new migration system comes into play.

My free time is opening back up a bit so I'll be back on this soon, plus I got a new community member @Ard2025 whose been helping me and will very likely be assisting me in the new migration development. I'm not going to close this bug, but just letting you know it's not a quick "bug" after review, but instead it's a fundamentally understood issue that will persist until this next feature is released.

But I want to start knocking out the migration aspect sooner vs later and I think in the next month or 2 it'll be both launched and refined :D I've been MIA for the past month or 2 because life is just taking over, but I'm regaining my time again!

[c-emin]

@magiccodingman I made a couple of changes and now I can name my Database at Runtime.
Do you see any issues with the way I am doing it?

//IndexDbContext.cs
public class IndexDbContext : IMagicRepository
{
    public static IndexedDbSet Client = new ("Client");    //Remove readonly
    //public static readonly IndexedDbSet Employee = new ("Employee");
    //public static readonly IndexedDbSet Animal = new ("Animal");
}

//Home.razor
if (firstRender)
{
    try
    {
        IndexDbContext.Client = new("MyCustomDBName");  //Name my Database

        var db = await _MagicDb.Database(IndexDbContext.Client);
        await db.DeleteAsync();
...

[Ard2025]

For me on the first time opening like this it throws an exception because the database doesn't exist. it will create the database and the next time it can open it (what probably will be after a relaunch of the app). The magicdb auto db connection can stay open so manual connection management might be required using this approach since without i has a issue where all operation on the second db didnt work. I used the code below to test your idea. On the first time opening the database it throws an exception in the browser because the database doesn't exist. second time it does exist and works. Maybe i am doing something wrong, but as far as I've figured out i would discourage this approach

var connection = await _MagicDb.Database(IndexDbContext.Client);
await connection.OpenAsync();
IMagicQuery<Person> personQuery = await _MagicDb.Query<Person>();
await personQuery.ClearTable();
await personQuery.AddRangeAsync(persons);
await connection.CloseAsync();
            
IndexDbContext.Client = new("OOF");
var connection2 = await _MagicDb.Database(IndexDbContext.Client);
await connection2.OpenAsync();
IMagicQuery<Person> personQuery2 = await _MagicDb.Query<Person>();
await personQuery2.ClearTable();
await personQuery2.AddRangeAsync(persons);
await connection2.CloseAsync();

Another issue i have with this approach is that it that setting IndexDbContext.Client might lead to confusion about the current database the variable is pointing to.

[c-emin]

I'm not using OpenAsync(). That might be where the exception is coming from for you.

This is what I did....

Using the standard code published as Magic IndexedDB v2.0.1
I made these changes to these 3 files

[magiccodingman]

@c-emin It'll work in certain scenarios, but not others. It's very bugged to be honest because the migration system is not fully deployed yet, so handling dynamic deployments doesn't really work. I'm going purely off memory right now, but if I remember correctly. It's something around the lines of it only working for pre-specified databases. But don't quote me on that, but it is disabled for a reason because it's incredibly unstable.