Add migrations to bump level ids by 200,000,000

[jvyden]

Some preliminary work for the big archive import. This will allow us to cleanly import everything while keeping all the old level ids from the original servers.

The number 200,000,000 was chosen because it's about double the amount of the highest ID recorded in the dry database, that number being 100,515,565.

The sooner we get this out, the lesser the impact this will have as people continue to upload levels.

Marking as draft because there are a few considerations:

• How do we handle website links? Every level link ever sent will break with this update.
  • We could introduce a new level route for the website, and redirect the old one, for example https://lbp.lbpbonsai.com/l/1234. There's also the old LBP.me links, like https://lbp.me/v/<some encoded int>.
  • We could just redirect and add 200,000,000 for now to keep it simple.
• Are the new foreign key definitions correct? Will it cause unexpected behavior?
• There may be some cases where the Level ID isn't referenced by a foreign key. An example of this is Events, but there could be more of these that I'm unaware of.
• This doesn't consider new databases.
• This might cause some unexpected behavior in-game, particularly with recently played levels (they're stored locally if I'm remembering correctly) but that's minor at best.

[Toastbrot236]

This will likely break level keys and level links (the in-game objects)

[jvyden]

True, but it also goes the other way... if we don't do this level keys & links will be broken in reuploaded levels.

I don't think there's much we can do about that, and I think most instances of keys are spam anyways. Level links are a bad thing to break though.

[jvyden]

Hmm... what do you think the viability of re-serializing levels is? Maybe that could be a solution - updating every level with a level link/keys with the new IDs? Only thing is we don't have any kind of infrastructure for that.

[Nya0]

It would not be a bad idea to get some simple infrastructure for that. might also be useful in the future. it seems to be the best option cuz whats proposed right now just seems like duct tape that we might regret in the future

[Nya0]

actually i dont know

[Toastbrot236]

For the infrastructure, maybe we could look into CwLibNet? I don't know how feature complete it is exactly (aside from seemingly having code for level links/keys), maybe if that doesn't work we could probably use CwLib to write a small Java program to migrate the data store? Just some random ideas

[jvyden]

I won't go into detail here but I'd like to avoid that library since we (Bonsai) have had issues with the maintainers of that project.

I was actually thinking we could just consume CwLib in a Java server. We already plan to support moving workers outside of the main GameServer, so maybe that could be an addition to that - we could have the C# worker queue up levels to migrate, and have the Java side migrate them. This would allow us to do other things that might require Toolkit aswell.

The downside to this is that it requires you to write Java.

[jvyden]

Oh, another route could be running CwLib directly within C#. I don't know how practical or usable they are for this case, but there exists a couple projects out there that will allow you to call Java from C#. That would let us skip all the boilerplate database code.

But maybe it's still worth it to just write a Java worker because I don't really see anything that's still maintained.