This project is read-only.

Feedback for upcoming 0.1.7

Mar 30, 2009 at 8:25 AM
If you have any feedback from release 0.1.6, please post it here.

The Tier system is roaring along. I'm taking the opportunity to make some more code format changes and clean-up the database a bit (removing duplicate queries, cleaning up table definitions, etc). There's a new "Boards" section where you can create different DKP systems with different module settings, and the Module's Settings have been updated to allow a site admin to select which Board each DKP module instance should display.

At first I thought this whole Tier system thing was going to hose the database, but it's really not that big of a deal. If you take a look at the database, you'll notice it uses a unique key driven system that has no meaning outside of the system. Because we use this value to manipulate existing data, we don't need to worry about which Board the player, item, mob, instance, or raid belongs to when editing or deleting. We only need to worry about the Board when adding. To those looking for a prime reason to use unique meaningless keys in a database, this is a great example.
Mar 31, 2009 at 9:12 AM
Tier upgrade is done!

In the new system, previously top-level database entities (Players, Items, and Instances) have now become children to the new top-level entity Boards. For new DKP installations, this isn't that big of a deal; but for existing systems, this is a pretty big deal because we have a lot of pre-existing data that needs to be brought in and bundled under a yet-to-exist Board.

Now if we just kept an unsecured list of Boards, this wouldn't be that big of a deal, but some people are a little more concerned about data integrity at the Host level. Due to this concern, Boards are actually separated from each other by PortalID. This means that if you have more than one portal running from the same DNN installation, Boards made from a DKP module instance in one portal will not be visible to a DKP module instance in another portal. From a Hoster's perspective, this is kind of important if you have multiple clients and you don't want one client to fubar another client's DKP Boards.

So if you haven't figured out the problem yet, here's the crap hitting the fan... in order to create and uphold integrity in the database, when you upgrade the module, we have to create a dummy Board, setup the integrity rules, and unite all the pre-existing data under this dummy Board. We do not know though, the PortalID of your site. Nor, at the time of module upgrade, can we determine this value.

So after upgrading the module, your data is going to disappear because it's bundled by the install script under a Board that has a PortalID value that doesn't match any portal you have on your site.

Freaky... but true.

To get your data back, after upgrading the module, the first time you go the new Boards section, we will identify if the dummy board has been initialized to your PortalID. If not, we'll execute some special code just this one time, tie the dummy Board to the PortalID we see the module instance on, and you'll see the default board.

Honestly, you shouldn't see anything out of the usual, but I thought you might like to know what kind of effort has to go into this stuff. :)
Mar 31, 2009 at 9:55 AM
Found something with Loot...

Apparently if you have someone that wins the same item twice, you're gonna run into a wall. I was just goofing around when I found this, so I then though... "Can this really happen?" And the answer unfortunately is yes, especially if you're gearing up a recent recruit on farm content that's getting sharded alot and you have two of the same slot, same class Tier armor tokens drop. I could see someone getting both drops, one for primary and one for secondary gear sets.

The odds of this though... wow, really slim. I've never seen it happen. If it ends up being an issue for anyone, let me know.