Default world data documents?

[DavidRieman]

As we migrate world data into the default document DB instances (Raven DB), we'll need be thinking about how we populate that initial world data. For comparison, for the current legacy SQLite world data we just copy the SQLite data from the systemdata\Files area to the application data. If we go that route with Raven DB too, we'll want to make sure that works well for that DB type too. I think it will, in general. However, we're also storing our local character data and such in the DB. We'll want to look into ways to "diff" the documents from a proposed PR update of the Raven DB default instance to see what's incoming, and verify there are no "players" and such accidentally stored in said initial DB. (We did this by hand for the SQLite DB but it was by no means trivial and won't be for RavenDB either.)

Some script or something to auto-strip players and such from said default DB before they reach master may be helpful?

Could use some further thought on this area...

[DavidRieman]

An alternate approach may be to have the default world all populated by some big C# code that just news up a bunch of Things and their Behaviors and then persists them to the initially-blank DB. This would be easy to diff but would be a lot of code for any sufficiently-sized default world.

Another thing to think about is whether systemdata\Files is really the right place for a default world DB... The initial world (including any custom world-specific Behavior class instances) is going to end up tied to the genre / rule set being demonstrated... e.g. specific world for Warrior Rogue and Mage versus some hypothetical future non-room-based space combat reference implementation, etc.

[ghost]

Hi David. I'm in the middle of intense language (hoo-mon, not computer!) language training at the moment so have no time after work these days for fun projects until I've seen that effort through.

One of the projects I'm considering to undertake is to create a sqlite JSON1 document data interface as an alternative to RavenDB. Before I go too far down this road in what little time I have I'm wondering if this was already considered and, if so, what were the pros/cons?

[ghost]

Personally, I'd go the route of creating an Initial Database Fill C# script. Id make it generic in the the way that it populates the data in order to allow easy swapping of database frameworks.

[ghost]

Hi David. I'm in the middle of intense language (hoo-mon, not computer!) language training at the moment so have no time after work these days for fun projects until I've seen that effort through.

One of the projects I'm considering to undertake is to create a sqlite JSON1 document data interface as an alternative to RavenDB. Before I go too far down this road in what little time I have I'm wondering if this was already considered and, if so, what were the pros/cons?

I'd shy away from using a custom sqlite (even json1 as it is stored as straight text and is under performant). Sqlite in general is a poor choice for mutable data.

[ghost]

I don't disagree with this but it'll be a luxury problem if I ever have to worry about scaling my MUD world beyond what sqlite can handle and I prefer to have to deal with the least number of dependencies as possible. I don't expect this to be the default choice but likely just a peculiarity of my own implementation.

[DavidRieman]

Indeed there would be trade-offs on the scalability/performance/flexibility/dependencies/comfort with any given tech, and so on.

• If your main goal is "least number of dependencies," I would prefer we accomplish that the other way, with eliminating what relational data we do have in SQLite by finishing migration of it into RavenDB.
• On flexibility: It will be challenging to build in the flexibility of a Document DB. Even the flexibility we already rely on (see PlayerRepositoryExtensions for example of Query usage) will be a big challenge to support.

However, the point of us building and maintaining Data layers in the way we do is to build choice into the framework. You ought to be able to build what you want (SQLite as a Document DB) and configure it to be used through App.config. If you managed to do it in a non-invasive manner (doesn't push conditional logic out to a bunch of Load sites) that supports those goals of choice, it would be likely to merge to main WheelMUD and remain a supported option. For example, at a high level the approach would probably look like:

• Make another library next to WheelMUD.Data.RavenDb and WheelMUD.Data.Sqlite like WheelMUD.Data.SqliteJsonDocumentDb or something.
• It would follow the RavenDB model of exporting like [Export(typeof(IWheelMudDocumentStorageProvider))].
• The returned class from CreateDocumentSession would implement IBasicDocumentSession. This is where the bulk of the challenge will be, as things like Query are meant to be a super-flexible way to inspect arbitrary properties of the objects. I imagine the starting implementation of Query would have to be something like "load all relevant objects into memory; replicate the query against that loaded collection, and return that query".