New tests (and fixed updated CardRequest implementation) verify that any method used for Card Retrieval when receiving directly CardRequest formatted strings as cardName won't have any side effect. In particular, the code is reliable to be robust enough to support passing in both card name (only) or a full cardRequest string.
If the latter, any parameter in the request will be updated - accordingly - only when explicit params in function calls are provided.
Also, new tests demonstrate that the current implementation has NO side effect when testing for multiple combinations. Therefore, whatever is requested in requestString won't be overruled, unless really requested too.
Clarified (imho) a ton my own previous wording about this option - also for Italian. Moreover, this update aligns all the "RESTART REQUIRED" labels with the same translation and case.
Also, it is important to emphasise that previous implementation of the "Strict" Card Art Preference policy were too stringent, and did not account for corner cases when the card could not be retrieved. This has been FIXED in the new API implementation.
Huge refactoring in variable names and test case optimisations. Also, new tests for the new API are also included. In particular, additional corner cases tested, as well as verification with Legacy (previous) CardDb implementation.
This new revision of the APi brings a more consistent distribution of the different parameters and settings in DB API calls.
In particular, the changes affect the getCardFromEditions which are now separated into three sets of methods:
- methods to retrieve a card based on CardArtPreference
- methods to also include a Release Date restriction,
that can be now considered in both directions
(as in "releasedBefore" and "releasedAfter" a specified date).
These changes will be functional for new additions in future changes to Deck Importer, as well as will be used
to refine the implementation of the new Smart Card Art Selection in Decks.
From an implementation perspective, it is important to emphasise that all those methods are just syntactic sugar
for parameter passing to the **same** core (private) retrieval method (centralised single point of failure)
which incorporates all the required parameters, that would also be cumbersome to use in a public API.
