Weapons decoration slots && Armor decoration slots (weird data) about mhwdb-docs HOT 9 CLOSED

@cheng1994 Sorry, reading over that again I'm realizing that my plan wasn't very clear.

In most cases, any change I make to an existing endpoint will be backwards compatible, with a deprecation notice in the changelog of the release detailing which future release or on what date the old information will be removed.

As far as this change goes, I'm going to leave the slotsRank# fields as they are in the attributes field. I'll be adding a slots field to the object itself that'll include the slot rank information, which should make (for example) armor objects look something like this (some fields are removed from the example below for brevity).

{
  "id": 505,
  "name": "Diablos Nero Coil Beta",
  "attributes": {
    "slotsRank2": 1
  },
  "slots": [
    {
      "rank": 2
    }
  ]
}

So in your case, your application can continue to function as is, giving you time to make the change over to the new format.

from mhwdb-docs.

Agree this would be a good change, I actually have something like this for my needs.

from mhwdb-docs.

@kclay what are you developing :O?

from mhwdb-docs.

I need to pick a format that works best with how the API is set up, but I'm thinking of changing slots to something like this:

{
    "slots": [
        1,
        1
    ]
}

{
    "slots": [
        2,
    ]
}

Basically, just an array with 0 to 3 elements, each one an integer representing the rank of the slot.

from mhwdb-docs.

@LartTyler I sorta like what @RayLuxembourg proposed. It allows easy attaching on other properties without any data remodeling. For instance, if I'm making a build simulator I would want my builder to show what slots I have and what deco is set on that slot. This can be achieved by simply doing

{
"slots":[
   {rank:1,deco:<decoId>}
   ]
}

Not really a big deal as we can always remodel the data client side, but it seems this would solve two use cases (mines and OP). Now as for the querying of this data. It looks like you are using mongodb Or does Mysql now allow json query been a while since I've used MySQL, saw you stated it on reddit. But with mongo I think you could do slots:{$in:{rank:1}}? Not sure if this is a valid query or what performance cost it may have.

from mhwdb-docs.

@kclay The backend is MySQL, not Mongo, but I built this library to translate Mongo-style queries to MySQL statements because I thought it was a decent way to handle searching endpoints. At the moment, I'm having issues working with MySQL's limited JSON functions in order to make something like {"slots":{"$in":{"rank":1}}} work.

The solution would be the move the slot data to it's own table, which would allow something like {"slots.rank":1} to work like you'd expect, returning any armor or weapon that has a rank 1 slot. Since you all seem to agree that the current format doesn't work, I'll get this added to the backlog. It's a simple enough change, so I'll plan on doing it next, after I finish up with #15.

from mhwdb-docs.

Nice library fooled me. Can't wait for #15 its really the only piece I'm missing right now for this builder. So for now I'm going to work on the searching and computing all the stats values.

from mhwdb-docs.

@LartTyler So to clarify you plan on moving slots to a separate key in each armor and weapon piece and then follow it with children with key rank? I'd like to prep my application for the change since I've already made slotsRank1 work in my case. But I'm more than open for improvements.

Also if anyone wants to take a look my application is at The Research Commision its still a work in progress

from mhwdb-docs.

Slot information has been migrated to the new format in v1.8.0.

from mhwdb-docs.