just because of the comments i understood that won or lost can be bigger than 1. should be defined a little more clearly, unless it is part of the kata that it is so cryptic.
You should drop the expect($sql.upcase).to include("LEFT OUTER JOIN").or include("LEFT JOIN") test as the kata can be competed with any type of join (except INNER).
Alternatively, you must add a note to the description, and (preferably) add this check to the sample tests.
I think the database design is a bit wonky. I think a better design might be separate tables for elements and Multiplers. Something like Elements(element_id, element_name and Multipliers(attacking_element, defending_element, multiplier). It was a bit unclear to me at first that the Multipliers table was only for pokemon attacking grass types (which works for this challenge, but, again, I don't think is a very well-designed structure).
I thought this could probably be considered a level 6 kyu, overall nice though, thanks.
just because of the comments i understood that won or lost can be bigger than 1. should be defined a little more clearly, unless it is part of the kata that it is so cryptic.
You should drop the
expect($sql.upcase).to include("LEFT OUTER JOIN").or include("LEFT JOIN")test as the kata can be competed with any type of join (exceptINNER).Alternatively, you must add a note to the description, and (preferably) add this check to the sample tests.
There should be an edge case where the
modifiedStrengthis in range(39, 40)to disallow wrong solutions like this one.I think the database design is a bit wonky. I think a better design might be separate tables for elements and Multiplers. Something like
Elements(element_id, element_nameandMultipliers(attacking_element, defending_element, multiplier). It was a bit unclear to me at first that theMultiplierstable was only for pokemon attacking grass types (which works for this challenge, but, again, I don't think is a very well-designed structure).