Design for AllPricesV2.json

[kodawah]

This proposal describes the creation of a new file, supplanting most of the functionality of the current AllPrices.json and expanding the number of data points. Among the limitations of the current solution there is the fact that the generated file is pretty big in terms of size, can only host one type of price and it providing redundant information.

Proposal
The current nested dictionary structure works on a top level view, but a few fields should be moved elsewhere since they are constant. The main element is represented as a dictionary containing a foil and nonfoil price (assuming the card can be both), or just one of them (depending on the foil properties).

• cardId: is the mtgjson hash of the card
• stroname: is the name of the source providing the data points
• price_type: is the type of price represented, for example "buylist" "low" "market" "retail"

"<cardId>": {
    "<storename>": {
        "<price_type>": {
             "foil": 0.0,
             "nonfoil": 0.0,
        },
        ...
    }
}

As noted this design offers for expansion in case new price type are added per store, or new stores are added.
The static properties such as currency and whether it's paper or online prices are per-store properties and should not be in the main data section.

"static": {
    "<storename>": {
        "printing_type": "paper",
        "currency": "EUR"
    },
    ...
}

Open questions

• is it ok to break compatibility with the current design? hopefully the added benefits justify it
• where to add the static data? meta could be a possibility but a new section could be added too
• should this be worked on for 5.1 or later?

[ZeldaZach]

Will be considering more opportunities with a new format that is better suited to our needs. This will be our tracking ticket for it.

[ZeldaZach]

@kodawah Where should date go in your proposed structure? There are arguments to put it at each level, but I'd like to hear your thought process